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1.  INTRODUCTION  AND  SCOPE 


1.1  Background 

This  report  presents  the  results  of  a  year  long  study  aimed  at  identifying  alternative 
strategies  for  automating  remote-office  (district  and  Sub-district)  information  collection 
and  handling  within  the  Indiana  Depanment  of  Highways  (IDOH).  Originally  presented 
to  the  Joint  Highways  Research  Project  (JHRP)  Board  in  December,  1986,  the  draft 
report  has  undergone  two  revisions  following  review  by  key  IDOH  personnel  and  admin- 
istrative groups.  In  particular,  detailed  review  comments  by  Mr.  Bill  Bonning  and  Mr. 
Tom  Stuper,  both  of  IDOH  Data  Services,  have  greatly  influenced  this  final  report. 

The  nature  of  information  handling  within  IDOH  but  outside  of  the  central  office 
has  developed  in  response  to  the  needs  of  dedicated  and  sincere  workers  trying  to  serve 
the  State  of  Indiana  in  the  highest  and  best  possible  way.  The  breadth  of  services  pro- 
vided by  IDOH  is  vast  and  most  of  these  services  require  a  large  level  of  information 
inanagement  and  processing.  Until  very  recently,  information  flow  and  data  handling  in 
support  of  these  activities  have  been  accomplished  completely  by  hand. 

Spawned  by  the  concerns  of  IDOH  Data  Services  Personnel  together  with  IDOH 
staff  throughout  the  State,  of^ce  automation  technology,  much  of  which  has  been  used 
for  some  time  at  the  central  office,  is  finding  its  way  to  the  remote  offices.  Looking 
toward  the  future  of  information  management  within  IDOH,  Data  Services  distributed  to 
each  district  during  1986,  one  or  more  personal  computer  (PC)  systems  configured  as 
shown  in  Table  1.  Each  of  these  systems  was  installed  as  a  stand-alone  workstation  at 
fairly  central  locations  within  each  office.  Initial  training  of  individuals  at  each  office 
was  initiated  and  a  PC  user's  group  was  formed.  This  distribution  was  intended  not  as  a 
means  of  completely  satisfying  the  needs  for  office  automation,  but  rather  as  a  prelim- 
inary "experiment"  to  see  how  this  technology  would  be  received  by  IDOH  district  staff. 


FINAL  REPORT  JULY,  1987 


WRIGHT.  KOSIBA  &  STUKEL 


page  2 


TABLE  1 :  District  Office  PC  Configuration 


HARDWARE 

SOI- 1  WARE 

IBM  PC/XT  Microcomputer 

PC-DOS  3.1  Operating  System 

-8088  Processing  Chip 

Fixed  Disk  Organizer 

-8087  Math  Coprocessor 

IBM  Filing  Assistant 

-640KB  RAM  Memory 

IBM  Reporting  Assistant 

-10  MB  Fixed  Disk  Storage 

IBM  Graphing  Assistant 

-360  KB  Floppy  Disk  Drive 

IBM  Planning  Assistant 

-EGA  Graphics  Card 

Lotus  1-2-3  Spreadsheet 

IBM  Enhanced  Color  Monitor 

IBM  Displaywrite 

Epxon  Dot  Matrix  Printer 

PARADOX  DBMS 

IBM  Quietwriter  Printer 

KEDIT  File  Editor 

Early  in  1986,  Data  Services  supported  a  proposal  for  the  present  study  to  help 
give  direction  to  this  spread  of  office-automation  technology  to  remote  sites  first,  by 
identifying  the  nature  and  extent  of  information  handling  activities  at  remote  locations, 
and  second  by  attempting  to  define  alternative  approaches  to  automate  those  systems. 
This  report  presents  the  findings  of  that  study.  A  general  summary  of  important  results  is 
presented  in  the  next  section  of  this  Chapter.  Chapter  2  describes  the  methodolog>'  fol- 
lowed in  collecting  data  and  presents  an  important  set  of  preliminary  observations  about 
information  management  throughout  IDOH  at  the  outset  of  the  project.  The  results  of  the 
study  are  presented  in  Chapter  3  referenced  to  a  complete  set  of  information  system 
profiles  included  as  an  Appendix  to  this  report.  The  final  chapter  of  the  report  — Chapter 
4 —  presents  some  recommendations  for  future  study  and  action. 


1.2  Summary  of  Results 

Results  and  recommendations  from  this  study  fall  into  two  categories:  1)  recom- 
mendations for  automating  existing  remote-office  information  systems  as  an  evolutionary 
extension  of  the  existing  hardware/software  system  (Chapter  3);  2)  recommendations  for 
revolutionary  changes  in  information  management  with  implications  for  IDOH  central 
office  computer  protocols  (Chapter  4).  The  first  category  is  satisfies  the  original  research 
objectives  of  this  project  while  the  second  extends  beyond  the  original  scope  of  work. 
While  a  much  larger  effort,  the  authors  support  the  revolutionary  approach.  A  general 
listing  of  all  results/recommendations  is  presented  below. 
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Some  84  separate  information  systems  are  routinely  used  by  IDOH  personnel  at 
remote  office  locations.  Relatively  few  of  these  presently  use  any  form  of  office 
automation  (section  2.3). 

Each  of  these  84  information  systems  could  be  automated  to  different  degrees  and 
with  different  levels  of  effon  (time  &  cost)  using  the  PC-based  hardware  and 
software  configurations  recently  provided  by  Data  Services  to  each  district  (section 
3.3). 

Serious  problems  would  be  expected  to  result  from  an  approach  to  automation  that 
would  use  these  systems  as  models  for  their  automated  counteipan  (section  3.4). 

A  better  approach  to  remote-office  automation  would  be  to  design  a  set  of  larger 
loosely  coupled  data  bases  that  would  be  distributed  at  an  appropriate  level 
throughout  IDOH  and  that  would  provide  much  more  comprehensive  information 
access  and  management  (section  4.1). 

Positions  should  be  created  for  computer  staff  persons  located  at  remote  offices 
who  can  administer  remote  hardware  and  software  systems  in  concert  with  central 
office  personnel  and  who  can  provide  training  and  support  for  users  (section  4.2). 

Incentives  should  be  provided  to  IDOH  remote-office  personnel  to  leam  and  use 
computer  technology  to  increase  overall  decision-making  efficiency  and  effective- 
ness (section  4.3). 
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2.  THE  NEEDS  SURVEY 


2.1  Introduction 

The  goals  of  this  research  were  1)  to  understand  and  document  how  information  is 
handled  at  IDOH  district  and  sub-district  offices,  2)  describe  the  information  systems 
presently  in  use,  3)  expose  those  information  systems  that  would  benefit  from  automa- 
tion, and  4)  suggest  new  ways  in  which  information  already  gathered,  coupled  with  new 
automated  systems  tools,  could  improve  decision  making  processes  throughout  IDOH. 

Managing  the  quantity  of  information  that  is  being  collected  in  the  IDOH  is  com- 
plex. What  is  required  is  an  understanding  of  what  information  is  being  gathered,  and 
why,  and  a  working  knowledge  of  who  should  be  allowed  access  to  this  information,  and 
in  what  form.  While  general  district  operations  are  essentially  the  same  throughout  Indi- 
ana, the  importance  placed  on  these  tasks  and  the  methods  and  personnel  used  vary 
significantly. 

The  method  used  to  capture  this  information  was  to  conduct  informal  interviews 
with  representatives  of  all  sections  in  every  district  office,  and  at  least  one  subdistrict 
office  in  each  district  A  wide  range  of  personnel  was  interviewed  from  top-level 
managers  to  clerical  staff  and  skilled  workers.  This  provided  insights  as  to  the  views  not 
only  of  those  responsible  for  the  content  of  information  used  at  remote  locations,  but  of 
those  who  actually  collect  and  handle  that  information.  We  learned  of  the  willingness  of 
some  IDOH  personnel  to  use  computers  as  well  as  reasons  for  the  reluctance  on  the  part 
of  some  others. 

This  study  began  with  a  series  of  interviews  with  IDOH  central  office  management 
personnel  representing  six  divisions  within  the  IDOH:  1)  Administration,  2)  Construc- 
tion, 3)  Development,  4)  Maintenance,  5)  Material  and  Testing,  and  6)  Traffic.  The  cen- 
tral office  interviews  were  followed  by  individual  site  visits  to  the  district  offices  located 
at  Vincennes,  Seymour,  Fort  Wayne,  Greenfield,  Crawfordsville,  and  LaPorte.  Personnel 
interviewed  at  each  district  office  ranged  from  departmental  secretaries  to  the  District 
Engineer.  The  goal  of  the  visits  was  to  gain  an  understanding  of  how  information  was 
processed  and  what  type  of  information  was  being  used  at  the  district  and  subdistrict 
office  in  administering  the  overall  mission  of  IDOH. 

Each  site  visit  began  with  a  general  meeting  with  the  District  Engineer  and  each 
section  head.  This  meeting  served  to  introduce  the  reasons  for  the  visit  and  allow  for  the 
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planning  of  the  interviewing  agenda.  The  informal  interviews  in  each  section  were  con- 
ducted over  1-week  period.  District  and  subdistrict  personnel  described  their  individual 
job  functions  and  were  allowed  to  express  a  "wish  list"  of  tools  that  would  make  their 
jobs  easier  or  better.  Through  these  interviews,  an  overall  picture  of  what  information  is 
required  to  maintain  the  IDOH  was  obtained,  as  well  as  possible  avenues  for  system 
improvements. 


2.2  Methodology 

Initially,  the  scope  of  this  study  was  restricted  to  information  systems  presently  in 
place  at  remote  offices.  The  goal  was  to  provide  recommendations  for  the  appropriate 
level  of  automation  (both  hardware  and  software)  only  for  existing  systems.  To  evaluate 
the  computer  needs  of  the  IDOH  it  was  first  necessary  to  know  what  information  was 
being  collected,  and  why,  and  to  compare  these  needs  relative  to  the  best  modes  of  opera- 
tion, both  automated  or  non-automated,  for  each  information  system.  A  three-step  pro- 
cedure was  followed: 

STEP  J:  Categorizing  and  Describing  Existing  Systems 

Exhaustive  interviews  were  scheduled  and  conducted  throughout  the  state  to  obtain  a  true 
perspective  on  the  type  and  quantity  of  information  used  in  the  daily  administration  of 
IDOH  activities.  Through  this  process,  some  250  IDOH  personnel  were  questioned  at 
vinually  all  levels  of  the  agency.  Careful  records  of  these  interviews  were  synthesized 
into  descriptions  by  functional  area.  Each  functional  area  was  thus  able  to  be  described 
by  a  set  of  information  systems. 

STEP  2:  Identifying  Information  Flow 

Once  the  systems  were  identified,  it  became  necessary  to  find  where  the  information  is 
collected,  who  needs  the  information,  who  can  use  the  information  to  support  decisions, 
and  in  what  form.  This  is  imperative  as  the  information  flow  within  a  system  will  likely 
influence  the  hardware  and  software  requirements.  TTierefore,  the  information  flow  of 
each  information  system  was  noted. 

STEP  3:  Developing  Information  System  Profiles 

For  each  information  system  identified,  a  brief  report  called  a  "profile",  was  drafted. 
Each  profile  presents  a  general  description  of  the  information  system  including  the  pur- 
pose, information  flow,  central  office  interface,  existing  forms,  and  additional  remarks. 
In  all  cases,  information  profiles  were  identified  through  observation  made  during  the  site 
visits;  they  were  not  an  attempt  to  explain  the  current  systems  outlined  in  IDOH  manuals 
or  presently  in  use. 

Preliminary  profiles  were  sent  to  each  district  office,  reviewed  by  district  person- 
nel, and  returned.  With  additional  input  from  the  districts  the  final  profiles  accurately 
describe  district  and  subdistrict  activities.  The  resulting  information  system  profiles  are 
appended  for  reference.   Each  profile  describes  an  information  system  currently  in  use 
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within  the  IDOH,  and  represents  a  target  for  potential  automation  over  a  wide  range  of 
computer  support,  from  a  dedicated  micro  computer  to  remote  access  on  an  existing  cen- 
tral computer.  An  important  result  of  this  study  was  this  categorization  and  description 
of  the  information  systems  being  used  by  IDOH. 

It  should  be  noted  that  each  of  these  systems  identified  was  labeled  without  con- 
sideration for  labels  presently  use  by  IDOH.  Hence  while  the.se  information  system 
names  may  commonly  be  used  to  describe  a  specific  function  within  IDOH,  the  reader 
should  assume  no  direct  relationship  between  the  information  system  label  and  these 
functions. 


2.3  Summary  of  Initial  Observations 

The  interviews  described  in  the  previous  section  took  place  over  a  2-month  period 
during  Summer  1986.  From  the  outset,  several  important  initial  observations  were  made 
and  continually  reinforced  as  additional  site  visits  were  made.  The  more  important  of 
these  impressions  are  presented  to  reflect  a  general  perspective  on  the  state  of  informa- 
tion management  at  that  point  in  time: 


1.  Existing  hardware  and  software  systems  are  used  (almost)  exclusively  for  data 
entry.  For  the  most  part,  personnel  in  the  district  and  subdistrict  were  very  open, 
encouraging  and  provided  extremely  thoughtful  comments.  In  each  case,  negative 
comments  about  the  existing  computer  system  resulted  because  of  the  feeling  that 
information  management  did  not  benefit  local  operations.  While  most  district  per- 
sonnel interviewed  were  not  computer  educated,  they  seem  willing  to  learn  new 
systems;  particularly  if  these  systems  are  shown  to  save  time,  or  improve  decision 
making.  Reluctance  and  skepticism  on  the  part  of  some  workers  was  usually 
traced  to  some  previous  negative  experience  with  computers  or  discouragement  at 
having  to  do  data  entry  with  no  perceived  purpose.  Generally,  district  personnel 
view  computer  work  as  extra,  or  duplicate  work,  as  keypunched  data  are  often  fol- 
lowed by  written  verification. 

2.  Data  collected  at  remote  sites  have  little  or  no  influence  on  decision  making  at 
those  sites.  It  is  also  important  to  educate  district  personnel  on  all  levels  in  the 
capability  of  any  new  system  and  allow  for  district  use.  Information  often  sent  to 
the  central  office  could  be  readily  used  in  the  districts  and  subdistricts  to  improve 
statewide  decision  making.  This  computer  hesitancy  could  be  eased  if  the  district 
personnel  reap  a  direct  benefit  from  their  efforts.  For  instance,  Crew  Day  Cards 
are  now  being  entered  into  the  central  office  mainframe  at  the  district  offices,  yet 
district  personnel  have  little  use  of  this  information,  and  serve  only  as  central  office 
keypunch  and  check.  They  could,  however,  make  use  of  this  information  in  a  rea- 
sonable monthly  or  weekly  form.  The  crew  day  card  system  should  return  to  the 
district  a  timely,  automated  report  as  a  benefit  of  the  keypunch  effort 
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3.  There  is  currently  a  large  amount  of  redundant  paperwork  being  done 
throughout  the  IDOH.  A  good  example  of  paperwork  redundancy  is  in  the  IDOH 
development  department's  Billboard  Inventory.  The  highway  beautification  act 
specifies  that  roadside  billboards  be  inventoried  every  six  months.  Central  office 
sends  each  district  two  copies  of  an  inventory  report  -  one  copy  is  updated  directly 
in  the  field,  the  other  remains  at  the  district  office.  The  second  copy  is  used  to 
make  "neater"  corrections  on  the  inventory  printout.  The  second  copy  is  sent  to  the 
central  office  where  a  development  division  secretary  pages  through  the  report, 
copying  each  billboard  update  on  a  separate  computer  form.  The  computer  forms 
are  sent  to  data  entry  personnel  and  entered  in  the  computer.  This  example  demon- 
strates three  areas  where  data  can  be  misentered;  when  data  are  transferred  from 
the  field  copy  to  the  second  copy,  when  data  are  transferred  to  the  computer  form, 
and  when  the  data  are  entered  in  the  computer.  There  are  many  such  systems  in 
the  IDOH  including  the  crew  day  card  system  and  the  construction  daily  reports. 

4.  The  PC  equipment  that  has  been  recently  been  placed  at  the  district  offices  is 
being  used  very  different  across  districts.  Last  year  each  district  received  two 
IBM  PC  XT's.  While  each  district  has  had  a  few  users  who  have  taken  to  the 
machines,  the  districts  of  Crawfordsville  &  LaPorte  have  taxed  the  machines  to 
their  fullest,  and  in  some  cases  require  a  rigid  1/2  hour  interval  time  schedule  to 
allow  users  time  on  the  machines.  PC  usage  in  the  districts  seems  to  be  propor- 
tional to  the  previous  PC  experience  of  the  district  personnel.  The  result  of  these 
constraints  is  that  some  divisions  in  each  district  have  received  adequate  computer 
exposure,  and  have  developed  many  PC  applications,  while  others  have  not. 

5.  Information  flow  between  districts  is  minimal,  and  best  served  by  non- 
automated  means.  At  all  levels  of  district  work,  inter-district  communication  was 
not  significant  enough  to  warrant  a  high  level  of  automation.  Most  communication 
seemed  to  deal  with  informal  trading  or  loaning  of  equipment  and  materials  and  is 
best  served  by  the  present  mode:  the  telephone.  While  an  IDOH  bulletin  board 
system  could  be  used  to  support  inter-district  communication,  a  special  effort  in 
this  vein  would  probably  not  be  cost  effective. 

6.  The  potential  for  cost  savings  through  increasing  the  overall  efficiency  of 
information  management  is  large  though  most  of  these  savings  would  result 
from  intangibles.  The  main  goal  of  the  IDOH  is  to  provide  a  high  level  of  service 
to  Indiana  residents.  While  financial  responsibility  is  important,  it  is  also  desirable 
to  increase  the  level  of  service  to  the  State.  A  primary  result  of  efficient  automa- 
tion is  large  increases  in  system  performance.  For  instance  a  roadway  history  is 
currently  being  kept  in  each  district  that  includes  information  on  large  maintenance 
and  construction  contracts.  If  this  system  were  to  be  automated,  the  capacity  for 
storing  and  retrieving  this  information  would  increase  dramatically.  The  capabihty 
to  store  information  such  as  daily  maintenance  activities  and  accident  and  signal 
histories  as   well   as  large  maintenance   and  construction   contracts  could   be 
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incorporated. 

The  cost  savings  become  apparent  when  the  applications  are  explored.  One 
possible  use  of  a  central,  complete  roadway  history  is  as  a  pavement  management 
tool.  By  knowing  the  composition  of  a  stretch  of  road,  as  well  as  it's  maintenance 
history,  it  would  be  possible  to  better  study  the  construction  of  new  roadways  and  a 
more  durable  road  would  save  the  State  immeasurably. 

Another  application  of  a  complete  roadway  history  could  be  to  answer  legal 
interrogatories.  If  this  system  could  produce  complete  roadway  reports,  time 
would  be  saved  scouring  files  for  such  information,  as  well  as  increase  the  profes- 
sional appearance  of  these  reports.  If  only  one  lawsuit  is  averted  or  won  due  to  a 
sophisticated  data  management  capability,  the  system  could  be  financially 
worthwhile.  Another  possible  avenue  of  improvement  is  in  interdepartment  com- 
munications. There  are  several  documented  cases  of  roadway  paving  soon  after 
painting  or  installing  raised  pavement  markers.  Installing  a  computer  calendar, 
where  all  projects  from  each  division  are  entered  and  updated  might  prevent  such 
an  occurrence  and  save  expensive  repainting,  or  reinstallation  of  the  markers. 

A  related  benefit  of  automation  would  be  in  public  perception.  Subdistricts 
report  large  time  delays  in  the  issuance  of  oversize/overweight  permits  due  to 
inefficient  system  design.  If  this  system  was  efficientiy  automated,  and  the  public 
served  faster,  this  would  have  a  direct  positive  impact  on  the  public  and  depart- 
mental view  of  IDOH  efficiency. 

It  should  be  noted  that,  in  most  cases,  these  intangible  benefits  would  result 
not  from  automating  existing  information  systems  but  from  the  implementation  of 
new  ones.  For  example,  there  is  no  present  formal  mechanism  for  interdepartment 
exchange  of  work  scheduling  information.  This  would  require  a  new  information 
to  be  designed  and  implemented,  perhaps  using  some  form  of  automation. 
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3.  SURVEY  RESULTS  AND  DISCUSSION 


3.1  Synthesis  of  Survey  Results 

The  methodology  described  in  a  previous  section  of  this  report  (section  2.2) 
resulted  in  the  identification  and  documentation  of  some  84  separate  information  sys- 
tems. A  profile  of  presenting  important  features  of  each  information  system  was 
prepared  and  are  provided  as  an  appendix  to  this  report.  In  developing  profiles  for  these 
systems,  six  evaluation  parameters  were  established:  1)  mode  of  use;  2)  information 
backup  and  recovery  requirements;  3)  system  security  requirements;  4)  computer  time 
requirements;  5)  auditability;  and  6)  data  integrity.  Each  of  these  parameter  will  be  dis- 
cussed prior  to  the  presentation  of  specific  results. 

1.  MODE  OF  USE!  This  parameter  addresses  the  way  in  which  a  particular 
user  might  best  interact  with  a  computer-based  information  system.  Mode  of  use 
reflects  a  presupposed  level  of  understanding  and  experience  on  the  part  of  the  user 
as  well  as  having  implications  for  the  hardware  and  software  required  to  support 
that  user  mode.  Five  (5)  levels  or  modes  of  system  use  have  been  identified  for 
purposes  of  this  study: 

1.  No  Automation — Some  information  systems  are  best  left  non-automated 
either  because  the  expense  of  any  level  of  automation  would  not  be  cost 
effective,  or  because  automation  would  tend  to  isolate  the  decision  maker 
from  the  system.  For  example,  the  final  construction  record  (see  Appendix) 
should  not  be  automated;  compiling  and  finalizing  this  report  serves  to  fami- 
liarize the  construction  with  the  complete  history  of  the  project  In  automat- 
ing this  report  preparation  process,  this  familiarization  might  be  lost.  How- 
ever, many  of  the  reports  included  within  the  final  construction  report  such 
as  daily,  weekly  and  monthly  status  reports  should  indeed  be  automated. 

2.  Local  Stand-Alone  Computer — ^There  are  many  instances  where  stand 
alone  computer  applications  would  enhance  day-to-day  activities  without  the 
need  to  transfer  data  to  or  from  the  computer  being  used.  These  activities 
would  best  be  served  by  a  centrally  located  stand-alone  (micro)computer. 
For  example  many  materials  test  analyses  could  be  done  by  single-purpose 
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programs  running  on  personal  computers. 

3.  Local  DBMS — An  important  consideration  in  the  optima]  design  of  an 
automated  information  management  system  is  the  location  of  data.  A  well 
thought  out  protocol  must  be  established  for  who  will  have  overall  resf)onsi- 
bility  for  the  "true"  data  set;  particularly  in  cases  where  the  possibility  of 
more  than  one  copy  of  the  data  at  different  locations  is  possible.  For  some 
information  systems,  it  is  clear  that  the  the  best  location  for  the  master  data 
set  is  the  remote  location.  For  others,  a  central  location  is  optimal.  For 
example,  on-line  inventory  data  would  best  be  maintained  at  the  districts, 
while  budget  and  accounting  data  should  reside  at  the  central  office. 

4.  Local  CPU  with  Remote  Data  Access — Even  if  the  actual  data  reside  at  the 
central  office,  those  data  may  be  needed  by  models  and  applications  at  the 
district  offices.  When  local  analyses  requires  remote  data,  those  applications 
might  best  be  served  by  a  local  CPU  that  can  access  and  "download"  data 
from  a  remote  host.  For  example,  information  on  State-v^-ide  road  closures 
might  be  needed  by  users  at  a  Sub-district  office  for  purposes  of  issuing  an 
oversized  vehicle  permit. 

5.  Remote  Data  Input/Access  Only — In  many  cases,  a  remote  workstation 
might  simply  be  used  to  request  information  from  a  central  computer  (either 
at  the  central  office,  or  a  CPU  located  in  the  district  office)  or  for  routine 
data  entry.  This  is  the  mode  of  use  presently  employed  at  district  offices 
throughout  EDOH. 

Mode  of  use  is  only  one  parameter  that  should  be  considered  in  determining  the 
appropriate  end-of-line  hardware  best  suited  to  automate  a  given  information  sys- 
tem. In  many  cases  one  type  of  hardware  can  be  used  to  function  in  more  than  one 
mode.  A  personal  computer,  for  example,  might  be  configured  for  modes  2-4. 

2.    BACKUP  &  RECOVERY  REQUIREMENTS:  if  information  is 

collected,  that  information  is  considered  important  and  should  either  be  protected 
against  loss,  or  some  mechanism  should  be  provided  to  insure  that,  if  loss  occurs, 
the  information  can  be  recovered.  However,  some  information  is  more  "important" 
than  other  information.  Because  information  backup  (providing  multiple  and  possi- 
bly archived  copies  of  data)  has  a  real  cost,  the  importance  of  data  for  particular 
information  systems  should  be  considered  in  any  hardware  and  software 
specification.  Information  backup  considerations  are  complicated  by  the  fact  that 
data  frequenUy  has  a  lifetime,  and  its  importance  t>'pically  changes  over  that  life- 
time. Some  data  might  only  be  important  for  a  short  period  of  time  but  loss  of  data 
during  that  time  might  be  severe.  Other  data  might  not  be  particularly  important, 
but  might  potentially  be  needed  for  a  long  period  of  time.  In  considering  the  level 
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of  backup  required  for  any  particular  type  of  information,  one  must  consider  the 
costs  of  recovering  those  data  vs.  potential  costs  of  not  being  able  to  do  so.  For 
purposes  of  this  study,  three  levels  of  backup  importance  have  been  established: 

HIGH:  Extremely  important  data  that  must  be  recovered  within  a  very  short 

time  of  being  lost. 

MEDIUM:  Data  are  important,  but  loss  would  not  be  catastrophic,  or  recovery, 
though  expensive,  would  always  be  p>ossible. 

LOW:  If  lost,  information  would  not  need  to  be  recovered,  or  recovery  of 

information  would  not  be  expensive. 

3.  SYSTEM  SECURITY!  Related  to  the  inherent  importance  of  information 
is  the  concern  that  some  information  might  require  special  access  restrictions.  For 
example,  personnel  data  such  as  wage  and  salary  histories  should  have  access 
privileges  only  for  those  individuals  whose  jobs  require  that  information.  Like 
backup  considerations,  data  security  is  specific  for  each  data  set  used.  For  exam- 
ple, inventory  data  may  properly  be  copied  and  read  by  a  large  group  of  individu- 
als but  only  changed  by  a  privileged  few.  Again,  three  security  levels  have  been 
identified  for  this  study: 

HIGH:  Permission  to  view  the  data  restricted  to  a  select  few.  Permission  to 

edit  the  data  restricted  to  that  individual  responsible  for  the  integrity 
of  the  data. 

MEDIUM:  Software  and/or  administrative  measures  are  sufficient  to  control 
read/copy  access  to  the  data  or  read/copy  access  unrestricted.  Edit 
permission  restricted  to  that  individual  responsible  for  the  integrity 
of  the  data  or  his  designate. 

LOW:  Read/copy  access  to  data  unrestricted.  Edit  permission  not  an  issue. 

4.  COMPUTER  ACCESS  TIME:  Careful  consideration  in  the  design  of 
an  information  system  should  be  given  to  the  amount  of  use  that  system  should 
expect.  System  performance  must  be  viewed  relative  to  the  number  and/or  fre- 
quency of  transactions  or  data/query  processes.  If  a  quantitative  estimate  of  sys- 
tem use  can  be  developed,  the  number  of  terminals  or  computers  can  be  deter- 
mined. Efficient  automation  will,  itself,  cause  shifts  in  system  use.  The  numbers 
presented  in  the  following  tables  reflect  our  estimate  of  maximum  hours/day 
computer/terminal  use  for  each  information  system.  Because  some  information 
systems  would  require  intense  computer/terminal  use  for  only  a  few  days  each 
month  or  quarter,  the  overall  estimate  of  stations  required  by  IDOH  division  is 
conservative.  In  addition,  because  some  functions  are  performed  by  different  divi- 
sions at  different  district  offices,  aggregating  levels  of  use  across  districts  is  some- 
what speculative. 
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5.  AUDITABILITY!  Some  information  systems  require  a  high  level  of  "audita- 
bility";  the  ability  to  trace  the  data  to  their  origins  or  to  the  individual  responsible 
for  some  type  of  authorization  relative  to  the  information.  Auditability  is  particu- 
larly important  for  transactions  involving  monetary  exchange.  While  security 
issues  pertain  to  limits  of  data  access,  auditability  is  concerned  with  identifying 
individuals  who  must  be  associated  with  specific  data.  Three  levels  of  auditability 
have  been  defined: 

HIGH:  Accountability  must  be  traceable  to  the  individual  with  responsibil- 

ity; authorization. 

MEDIUM:       Accountability  may  be  traced  to  working  group  or  division.  Can  be 
used  to  verify  or  monitor  data  collection,  transfer  or  analysis. 

LOW:  Not  an  issue  as  information  is  temporary  or  task  specific. 

6.  DATA  INTEGRITYl  This  refers  to  the  accuracy,  completeness  and/or 
correctness  of  the  information  at  the  time  that  information  is  used  in  a  decision- 
making activity.  This  can  range  fi-om  information  that  MUST  be  accurate,  com- 
plete and  correct  at  the  time  of  input,  to  data  where  one  or  more  of  these  factors 
may  not  be  important  or  will  be  "caught"  somewhere  down  the  line.  Integrity  is 
particularly  complex  where  multiple  copies  of  a  data  set  must  be  used  at  separate 
locations.  It  must  emphasized  that  while  technologies  are  available  to  insure 
integrity  of  information,  these  technologies  are  expensive  and  should  be  used  spar- 
ingly. Three  categories  of  information  integrity  have  been  specified: 

HIGH:  Data  must  be  accurate,  complete  and/or  correct  prior  to  use  in  all 

circumstances. 

MEDIUM:       Inaccurate,  incomplete  and/or  incorrect  information  will  be  caught 
and  corrected  when  failure  to  do  so  will  cause  significant  expense. 

LOW:  Accuracy  and  completeness  is  not  important  and  incorrect  data  will 

be  caught  and  corrected  when  failure  to  do  so  will  cause  significant 
expense. 


3.2  Information  Systems  Tables 

An  evaluation  of  important  information  systems  at  district  and  Sub-district  IDOH 
offices  (by  division)  are  presented  in  this  section  of  the  report.  The  information  system 
tables  (Tables  2-8)  summarize  the  design  criteria  for  automating  each  information  sys- 
tem profile.  Included  are  the  aforementioned  parameters;  modes  of  use,  backup  and 
recovery,  security,  time  of  use  required,  auditability,  and  data  integrity  for  each  profile. 
It  should  be  noted  that  these  are  are  not  the  only  parameters  to  be  considered;  adequate 
software  design  in  support  of  each  information  system  is  assumed. 
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3.2.1  Administration  Information  Systems 

The  administration  office  in  the  districts  serves  to  coordinate  district  activities  and 
disburse  instructions  from  the  central  office.  This  makes  this  division  unique  in  that  they 
can  serve  as  an  assembling  point  for  all  data  coming  in  and  out  of  the  district.  A  sum- 
mary of  criteria  for  automating  Administration  information  systems  is  presented  in  Table 
2. 

An  important  consideration  in  designing  the  automated  information  systems  is  the 
"ownership"  of  the  data.  That  is,  who  is  responsible  for  the  data  and  who  updates  and 
makes  decisions  based  upon  this  data.  The  mode  of  use  will  define  data  ownership.  For 
instance,  affirmative  action  reports,  safety  records,  personnel  records,  payroll  records, 
and  Administration's  inventory  would  be  best  served  by  granting  ownership  of  the  data 
to  the  Administration  division.  It  is  also  important  for  each  of  these  systems  to  allow 
data  retrieval  by  other  users.  Therefore,  the  best  mode  of  operation  would  be  a  local 
DBMS  owned  and  controlled  by  Administration  with  links  to  central  office  and  other 
divisions. 

Another  important  consideration  when  discussing  the  mode  of  use  for  an 
automated  information  system  is  the  importance  of  data  access  or  data  communication. 
For  instance,  inventory  management,  utility  bill  management,  and  payroll  vouchers  are 
systems  that  require  Administration  input,  yet  other  divisions  or  central  office  should 
retain  control  over  the  data.  In  this  case,  a  local  CPU  with  a  data  link  would  best  serve 
the  IDOH. 

An  important  change  should  be  incorporated  into  any  automated  inventory 
management  system.  Presently  all  inventories  are  kept  at  the  central  office  and  are 
updated  annually  or  bi-annually  in  the  districts.  A  more  efficient  system  would  allow 
local  control  over  the  inventories,  allowing  each  division  to  keep  a  running  inventory 
which  is  periodically  sent  to  Administration  and  central  office.  Therefore,  the  adminis- 
trative control  would  be  a  local  CPU  with  data  access,  while  each  division  would  "own" 
it's  inventories  and  have  a  local  DBMS  with  data  transfer. 

Many  systems  do  not  require  district  administrative  inquiry.  For  example,  the  dis- 
trict serves  to  only  collect  and  pass  along  information  contained  in  the  requisition,  vehi- 
cle control,  and  petty  cash  systems.  Administration  does  not  have  any  use  for  this  infor- 
mation on  a  routine  basis  except  to  enter  the  information  and  to  check  the  validity  of  the 
information.  It  would,  therefore,  be  preferable  to  design  the  system  to  be  used  for  remote 
data  input  and  access  only. 

It  is  important  to  note  several  systems  which  are  indigenous  to  each  division. 
These  are  payroll,  vehicle  control,  requisitions,  and  inventories.  Just  as  in  the  case  of 
inventory  management,  payroll  should  be  checked  by  administration.  Each  division 
should  continue  to  submit  pay  vouchers  to  administration.  Administration  would  serve  as 
keypunch  and  check,  and  could  use  this  information  locally  in  the  form  of  payroll 
records.  The  system  could  be  broadened  to  include  personnel  records  and  safety  records 
as  well  as  payroll  records. 
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Table  2:  ADMINISTRATION  INFORMATION  SYSTEMS 


Information  System 

M 

B 

S 

T 

A 

I 

Inventory  Management 

4 

M 

M 

3 

H 

H 

Affirmative  Action 

3 

L 

M 

1/2 

M 

L 

Utility  Bill  Management 

4 

M 

M 

1 

H 

H 

Safety  Records 

3 

M 

H 

1 

M 

M 

Personnel  Records 

3 

H 

H 

3 

H 

H 

Payroll  Records 

3 

H 

H 

4 

H 

H 

Fuel  Inventory 

4 

M 

H 

2 

H 

H 

Petty  Cash 

5 

M 

H 

1/2 

H 

H 

Payroll 

4 

H 

H 

2 

H 

H 

Vehicle  Control 

5 

L 

L 

2 

M 

M 

Requisition 

5 

M 

H 

3 

H 

H 

Inventory 

3 

M 

H 

1 

H 

H 

M  -  Mode  of  use: 


1  =  No  automation  recommended 

2  =  Local  dedicated  CPU 

3  =  Local  DBMS  with  data  transfer 

4  =  Local  CPU  with  data  access 

5  =  Remote  data  input/access 


B  -  Backup  &  Recovery: 

S  -  Security: 

T  -  Time  of  use:  (hours  per  day) 

A  -  Auditability: 

I  -  Integrity  of  data: 


L  -  Low  concern 
M  -  Medium  concern 
H  -  High  concern 
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An  important  consideration  is  backup  and  recovery  of  administrative  systems.  For 
instance,  it  is  very  important  that  payroll  records  are  not  lost  or  corrupted.  Therefore, 
when  designing  an  automated  payroll  system,  special  care  should  be  taken  to  insure  that 
the  data  can  be  recovered.  Opposite  of  the  payroll  system  would  be  the  vehicle  control 
systera  If  the  weekly  vehicle  updates  were  lost  this  could  easily  be  recovered  with  the 
next  weeks  vehicle  update. 

Administration  routinely  works  with  sensitive  information  systems.  Safety,  per- 
sonnel, and  payroll  records  are  all  systems  where  security  is  a  prime  concern.  Access  to 
these  systems  should  be  limited  and  password  protected. 

For  each  administration  information  system  an  estimate  of  the  maximum  daily 
usage  was  made.  Inventory  management,  requisitions,  personnel  records,  and  payroll 
were  seen  as  systems  that  would  require  the  most  computer  time  on  their  busiest  days. 
With  full  automation,  it  is  estimated  the  the  heaviest  computer  use  day  of  any  month 
would  require  some  23  person  hours  within  the  Administrative  division  of  the  average 
district  Assuming  8-hour  work  days,  3  computer  stations  (total  keyboards)  would  be 
sufficient  to  carry  this  maximum  load. 

The  ability  to  audit  system  additions  and  deletions  is  critical  on  many  administra- 
tive systems.  Inventory  management,  personnel  records,  payroll  records,  utility  bill 
management,  fuel  and  equipment  inventories,  and  petty  cash  records  must  be  designed 
such  that  all  transactions  can  be  monitored  and  audited. 

For  many  of  the  administrative  systems,  it  is  important  that  data  residing  in  dif- 
ferent offices  concur.  Inventories,  personnel  records,  payroll  records,  and  all  requisitions 
must  agree  between  offices.  It  is  imperative  that  data  integrity  be  a  strong  concern  for 
these  administrative  systems. 

3.2.2  Construction  Information  Systems 

The  construction  office  in  the  districts  serve  to  coordinate  all  contracted  mainte- 
nance and  construction  projects.  Included  is  the  creation  of  all  contract  agreements  as 
well  as  daily  reports  and  contractor  correspondence,  which  monitor  construction  pro- 
gress. A  summary  of  Construction  information  systems  at  remote  offices  is  presented  in 
Table  3. 

As  mentioned  earlier,  one  of  the  important  benefits  of  automation  is  the  extraction 
of  progress  reports  out  of  a  local  DBMS.  One  system  that  would  clearly  benefit  from 
such  automation  is  the  daily,  weekly,  and  monthly  construction  progress  reports.  With  a 
local  DBMS  with  data  transfer,  much  time  would  be  saved  by  combining  these  systems 
and  allowing  for  the  extraction  of  these  reports.  The  reports  would  be  more  accurate  and 
would  allow  inclusion  of  other  items  of  concern  to  the  construction  engineer,  such  as 
comments  and  contractor  correspondence  as  well  as  a  copy  of  the  contracts  and  subcon- 
tracts themselves. 

Most  of  the  information  in  construction  systems  are  easily  reproduced.  Therefore, 
while  there  must  be  a  backup  protocol,  it  is  not  a  major  concern.  One  exception  would 
be  in  the  case  of  extra  work  agreements  and  contracts.  It  is  important  that  these  are  not 

FINAL  REPORT  JULY.  1987 


Table  3:  CONSTRUCTION  INFORMATION  SYSTEMS 


Information  System 

M 

B 

S 

T 

A 

I 

Monthly  Project  Reports 

3 

M 

L 

1/2 

M 

M 

Final  Construction  Record 

1 

- 

- 

- 

- 

- 

Contract  Correspondence 

1 

- 

- 

- 

- 

- 

Extra  Work  Agreements 

3 

H 

M 

1 

H 

H 

Daily  Reports 

3 

M 

L 

3 

M 

M 

Contract  Completion  Reports 

4 

M 

M 

1/2 

M 

M 

Subcontracts 

3 

M 

L 

1 

M 

L 

Contractor  Performance 

3 

L 

H 

1/2 

M 

H 

Inspector  Assignment 

2 

L 

L 

1/2 

L 

- 

Weekly  Project  Reports 

3 

M 

L 

1 

L 

L 

Payroll 

1 

- 

- 

- 

- 

- 

Vehicle  Control 

5 

L 

L 

1/2 

L 

L 

Requisition 

5 

M 

H 

1 

H 

H 

Inventory 

3 

M 

H 

1/2 

H 

H 

M  -  Mode  of  use: 


1  =  No  automation  recommended 

2  =  Local  dedicated  CPU 

3  =  Local  DBMS  with  data  transfer 

4  =  Local  CPU  with  data  access 

5  =  Remote  data  input/access 


B  -  Backup  &  Recovery: 

S  -  Security: 

T- Time  of  use:  (hours  per  day) 

A  -  Auditability: 

I  -  Integrity  of  data: 


L  -  Low  concern 
M  -  Medium  concern 
H  -  High  concem 
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lost  or  corrupted,  and  therefore  there  must  be  periodic  backups  programmed  into  an 
automated  contract  system. 

Another  area  of  equal  importance  to  the  design  of  a  secure  system,  is  the  proper 
design  of  an  "un-secure"  or  public  system.  Many  construction  systems  should  be 
designed  so  security  is  relaxed  enough  such  that  any  interested  IDOH  employee  can 
access  information  of  interest.  Such  is  the  case  of  the  daily,  weekly,  and  monthly 
reports.  If  it  is  necessary  to  check  on  the  progress  of  a  project,  or  the  next  scheduled 
activity,  this  information  should  be  accessible.  Therefore,  the  system  should  be  designed 
with  security  as  a  low  concern.  On  the  other  hand,  contractor  performance  is  a  sensitive 
report  that  should  only  be  seen  by  authorized  employees.  This  system  would  rate  secu- 
rity as  a  high  concern. 

Properly  automated,  construction  would  increase  efficiency  such  that  time  dedi- 
cated to  each  of  these  systems  is  minimal.  The  time  required  to  complete  contracts, 
weekly  reports,  monthly  reports,  and  contract  completion  reports  would  be  almost 
insignificant.  However,  in  order  to  automate  the  project  progress  reports,  a  concerted 
effort  must  be  made  to  compile  and  enter  all  daily  progress  reports.  The  estimated  daily 
usage  reflects  this  fact.  A  conservative  estimate  for  the  maximum  computer  time 
requirement  for  automating  these  systems  is  10.5  person  hours  per  day. 

While  many  of  the  construction  systems  should  be  accessible  enough  to  extract 
reports,  there  should  be  designed  into  many  systems  auditability  measures.  For  instance, 
contractor  performance  reports,  extra  work  agreements,  and  contract  completion  reports, 
should  include  an  accounting  routine  to  keep  track  of  who  is  responsible  for  editing  these 
documents.  For  the  contractor  performance  systems  and  extra  work  contracts  it  is  an 
important  concern  that  data  residing  in  different  locations  be  consistent.  All  contract 
wording  should  agree  in  both  the  district  offices  and  central  office.  Therefore,  an  impor- 
tant feature  of  such  a  system  is  assurance  of  data  integrity. 

3.2.3  Development  Information  Systems 

The  Development  Office  plays  a  very  diverse  roll  in  the  district  Included  is  the 
responsibility  for  the  approval  of  driveway  permits,  for  all  survey  work  done  by  the  dis- 
trict, for  simple  intersection  design,  for  maintaining  a  roadlife  history,  and  for  public 
relations  and  communications.  Another  vital  function  of  the  Development  Office  is  the 
co-ordination  of  many  engineering  functions.  Development  most  often  requires  input  for 
their  projects  from  other  divisions,  and  supplies  input  to  other  divisions  and  central 
office.  A  summary  of  important  information  systems  within  this  division  together  with 
considerations  for  automation  are  presented  in  Table  4. 

Development  is  unique  in  that  many  of  it's  activities  do  not  have  to  be  communi- 
cated to  central  office.  The  results  of  survey  operations  and  engineering  calculations 
need  to  be  communicated,  but  the  calculations  do  not.  For  such  systems  a  local  dedi- 
cated CPU  would  be  the  best  mode  of  automation. 

Many  of  Developments  systems  are  inventories  by  nature.  There  is  a  billboard 
inventory,  a  bridge  log,  and  a  railroad  crossing  inventory,  as  well  as  equipment 
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Table  4:  DEVELOPMENT  INFORMATION  SYSTEMS 


Information  System 

M 

B 

S 

T 

A 

I 

Roadlife  Log 

4 

H 

L 

4 

H 

L 

Bridge  Log 

3 

L 

L 

1/2 

L 

M 

Permits 

3 

H 

M 

1 

H 

M 

Billboard  Inventory 

3 

M 

L 

1 

H 

H 

Railroad  Crossing  Inventory 

3 

M 

L 

1 

L 

M 

Survey  Operations 

2 

M 

L 

4 

M 

L 

Design  Operations 

2 

L 

L 

4 

M 

L 

Public  &  Utility  Information 

2 

L 

L 

1 

M 

L 

Right  of  Way  Inventory 

4 

H 

L 

1 

M 

H 

Payroll 

1 

- 

- 

- 

- 

- 

Vehicle  Control 

5 

L 

L 

1/2 

L 

L 

Requisition 

5 

M 

H 

1 

H 

H 

Inventory 

3 

M 

H 

1/2 

H 

H 

M  -  Mode  of  use: 


1  =  No  automation  recommended 

2  =  Local  dedicated  CPU 

3  =  Local  DBMS  with  data  transfer 

4  =  Local  CPU  with  data  access 

5  =  Remote  data  input/access 


B 

-  Backup  &  Recovery: 

S- 

Security: 

T 

-Time  of  use:  (hours 

per 

day) 

A 

-  Auditability: 

I- 

Integrity  of  data: 

L- 

M 

H- 

Low  concern 
-  Medium  concern 
■  High  concern 
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inventories  common  to  each  division.  As  discussed  before,  it  is  imperative  that  these 
inventories  are  "owned"  and  controlled  by  Development,  and  the  communication  of  the 
information  is  automated.  Therefore,  a  local  DBMS  with  data  transfer  is  preferred. 

An  important  benefit  of  district  automation  is  the  inclusion  of  a  complete  roadlife 
log.  Presently  Development  keeps  a  chart  of  major  roadway  contracts.  Once  the  system 
is  automated,  regular  roadway  and  signal  maintenance  may  be  added  to  the  data  bank. 
This  roadway  history  would  best  be  served  by  giving  "ownership"  of  the  data  to  the  cen- 
tral office,  but  allowing  data  access  and  input  to  a  local  district  CPU. 

Several  of  Development's  systems  require  important  backup  protocols.  The 
roadlife  log,  the  driveway  permits,  and  the  right  of  way  inventory  would  best  be  subject 
to  frequent  data  backups,  as  accurate  and  timely  information  is  vital. 

As  Development  is  often  a  service  organization  for  the  other  divisions,  many  of  the 
information  systems  in  Development  should  be  easily  accessed  by  the  other  divisions. 
The  roadlife  log,  as  well  as  Development's  many  inventories  should  be  "public"  systems 
available  for  use  by  the  required  or  interested  IDOH  employee. 

As  with  the  other  divisions,  system  use  will  fluctuate  according  to  the  important 
activity  of  the  day.  It  is  easily  foreseeable  that,  with  appropriate  engineering  software, 
the  demand  for  design  operations  will  peak  as  a  design  is  due,  and  inight  take  full  use  of 
a  dedicated  CPU  for  as  many  as  four  hours  in  a  given  day.  Similarly,  both  surveying 
software  and  the  roadway  history  could  keep  a  dedicated  CPU  busy  as  long,  as  applica- 
tions become  apparent.  Maximum  month-day  use  within  the  Development  division  is 
estimated  at  19.5  hours. 

The  ability  to  audit  the  permit  system  and  the  billboard  inventory  is  important,  as 
both  systems  involve  the  issuance  of  public  licenses,  and  involve  the  public  trust.  As  the 
importance  of  the  roadlife  log  increases  to  include  roadway  and  signal  maintenance,  the 
importance  of  the  log's  audit  will  increase.  It  will  become  imperative  to  be  able  to  track 
the  person  responsible  for  the  data,  or  the  data  entry. 

Data  integrity  becomes  crucial  to  an  inventory  when  an  inventory  supports  the 
decision  making  process.  The  right  of  way  inventory  supports  surveying  operations  as 
well  as  design  operations  and,  therefore,  the  accuracy  of  the  data  must  be  assured. 

Similarly,  the  billboard  inventory  can  be  used  to  determine  dismantling  orders  and 
legal  liability  for  the  billboard.  Thus,  data  residing  in  central  office  and  the  district 
Development  office  must  concur. 


3.2.4  Maintenance  Information  Systems 

The  Maintenance  Division    in  the  di 
ing  all  district  Maintenance  activities.  Included  is  the  responsibility  for  the  Maintenance 


The  Maintenance  Division    in  the  district  office  plays  an  important  role  in  manag- 
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Management  System,  the  Preventive  Maintenance  System,  the  Pavement  Management 
System,  and  the  Winter  Transfer  Employee  System.  Many  of  these  systems  require 
extensive  input  from  each  subdistrict  in  the  form  of  manhour  reports  and  work  progress. 
This  lends  itself  well  to  automation;  information  gathered  by  the  subdistrict  for  central 
office  can  easily  be  put  into  meaningful  district  reports.  Relevant  parameters  for  automa- 
tion of  Maintenance  division  information  systems  are  presented  in  Table  5  . 

district  maintenance  keeps  several  important  inventories.  In  addition  to  mainte- 
nance equipment  inventories  there  are  the  Building  and  Grounds  Inventory  and  the 
Bridge  Inspection  Log.  As  is  the  case  of  most  other  IDOH  inventories,  the  best  mode  of 
operation  for  these  systems  would  include  local  control  of  the  systems  with  a  local 
DBMS  with  data  transfer. 

Maintenance  Management  should  become  controlled  at  the  district  level. 
Presently,  this  is  passed  from  the  central  office  to  the  district  in  the  form  of  a  budget 
book.  An  automated  Maintenance  Management  System  would  enable  the  district  offices 
to  retrieve  data  from  subdistrict  Crew  Day  Cards  and  make  comparisons  of  work  accom- 
plished versus  work  planned. 

Similarly,  it  would  be  feasible  to  control  the  Preventive  Maintenance  System  at  the 
district  office.  Preventive  Maintenance  would  be  more  timely,  and  the  level  of  service  to 
district  vehicles  and  equipment  would  improve.  Of  course,  the  information  contained  in 
the  system  might  be  needed  in  central  office  as  well  as  in  each  subdistrict  office.  There- 
fore, the  best  mode  of  operation  would  be  a  local  DBMS  with  data  transfer. 

There  are  several  systems  in  which  backup  and  recovery  are  important.  As  the  dis- 
tricts become  responsible  for  these  systems,  special  care  must  be  considered  for  backup 
and  recovery.  If  the  data  for  the  Preventive  Maintenance  System  and  the  Maintenance 
Management  System  is  to  be  kept  in  the  district,  special  steps  should  be  taken  to  ensure 
this  data  are  not  lost. 

Security  of  district  maintenance  systems  is  not  a  vital  concern.  Further,  it  might  be 
appropriate  to  allow  access  to  these  systems  to  most  district  personnel. 

The  Preventive  Management  System  and  the  Maintenance  Management  System 
are  seen  as  the  most  computer  intensive  systems,  in  terms  of  rime.  With  automation,  the 
Maintenance  Management  System  would  be  a  powerful  tool  that  could  be  used  by 
several  different  maintenance  engineers  for  many  different  purposes.  At  least  two 


Recall  that  "Maintenance"  and  "Sub-district"  are  separate  entities  for  purposes  of  this  study  while  in 
aciualiiy,  Sub-dislricts  are  administered  by  the  Maintenance  divisions  of  each  districL 
A  separate  computer-based  "Maintenance  Management  System"  has  been  ongoing  in  support  of  the 
activities  of  this  division  for  the  past  several  years.  The  present  software  for  this  system  resides  on  the 
mainframe  computer  in  the  IDOH  central  office.  The  information  systems  presented  in  Table  5  are  in 
no  way  connected  to  the  program  elements  of  that  system.  It  is  h>polhcsizcd  that  aulomaiion  of  many 
of  the  systems  presented  in  that  table  would  duplicate  the  tasks  being  designed  into  the  present  effort. 
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Table  5:  MAINTENANCE  INFORMATION  SYSTEMS 


Information  System 

M 

B 

S 

T 

A 

I 

Preventive  Maintenance  System 

3 

H 

M 

4 

M 

M 

Crew  Day  Cards 

4 

M 

L 

1 

M 

H 

Winter  Transfer  Employee  Report 

3 

M 

L 

1 

M 

H 

Building  &  Grounds  Inventory 

3 

M 

L 

1 

L 

M 

Bridge  Inspection  Log 

3 

L 

L 

2 

M 

L 

Maintenance  Management 

3 

H 

M 

3 

M 

H 

Pavement  Management 

3 

L 

L 

1 

L 

L 

Payroll 

1 

- 

- 

- 

- 

- 

Vehicle  Control 

5 

L 

L 

1/2 

L 

L 

Requisition 

5 

M 

H 

1 

H 

H 

Inventory 

3 

M 

H 

1/2 

H 

H 

M  -  Mode  of  use:       1  =  No  automation  recommended 

2  =  Local  dedicated  CPU 

3  =  Local  DBMS  with  data  transfer 

4  =  Local  CPU  with  data  access 

5  =  Remote  data  input/access 

B  -  Backup  &  Recovery: 

S  -  Security: 

T  -  Time  of  use:  (hours  per  day) 

A  -  Auditability: 

I  -  Integrity  of  data: 

L  -  Low  concern 
M  -  Medium  concern 
H  -  High  concern 
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computer  stations  would  be  required  to  handle  the  maximum-use  day  each  month  in  the 
Maintenance  division  and  it  is  anticipated  that  proportionally  more  high-use  days  would 
occur  in  this  division  than  in  most  others. 

Maintenance  systems  are  not  as  sensitive  to  intentional  or  unintentional  abuses, 
and  therefore,  auditability  is  not  a  major  concern.  There  are  several  systems  in  which 
data  integrity  becomes  significant.  The  Winter  Transfer  Report,  the  Maintenance 
Management  System,  and  Crew  Cay  Cards  all  contain  information  that  must  be  con- 
sistent wherever  the  data  resides. 

3.2.5  Materials  and  Test  Information  Systems 

The  logistics  of  sample  management  for  the  IDOH  is  complex.  Samples  must  be 
taken  for  each  material  used  on  IDOH  projects  and  then  be  tested  and  analyzed  at  various 
locations  in  the  State  before  the  material  is  approved.  Approval  of  the  samples  must  be 
timely  as  construction  may  wait  for  testing  results.  Thus,  system  efficiency  becomes 
significant.  A  summary  of  important  factors  in  automating  information  systems  within 
the  materials  and  testing  division  is  presented  in  Table  6. 

Sample  analysis,  like  engineering  calculations,  can  be  easily  automated  and  are 
best  served  by  a  local  dedicated  CPU.  This  system  can  include  a  test  repon  generator 
which  would  report  the  results  to  central  office  if  required.  With  this  system  enhance- 
ment, a  local  DBMS  with  data  transfer  would  be  best. 

The  independent  assurance  system  and  aggregate  certification  could  be  automated 
so  data  could  be  retrieved  from  the  central  office  and  the  systems  monitored  by  the 
interested  party.  This  would,  of  course,  require  a  local  CPU  with  data  access. 

It  is  important  that  all  materials  and  tests  be  accounted  for.  Therefore,  independent 
assurance  tests,  sample  management,  and  all  test  reports  must  be  backed  up  regularly. 
These  tests  cannot  be  lost.  The  security  of  these  systems  are  not  a  major  concern. 
Interested  employees  should  be  allowed  access  to  tests  of  interest. 

Material  analysis  and  test  reports  presently  take  the  most  time  within  the  Material 
and  Test  office.  This  would  continue  to  be  the  case,  as  the  systems  are  better  automated. 
Peak  system  use  each  month  is  anticipated  to  be  12  person-hours. 

The  nature  of  the  tests  would  imply  that  auditability  be  a  major  concern  when 
automating  these  systems.  The  originator  of  all  test  reports,  aggregate  certification  tests, 
and  independent  assurance  tests  must  be  noted. 

It  is  important  that  the  results  of  any  sample  tests  be  consistent  wherever  the  data 
may  reside.  Data  located  in  the  central  office  must  concur  with  the  results  in  the  districts, 
and,  therefore,  data  integrity  takes  an  important  role  in  designing  Material  and  Test's  sys- 
tems. 
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Table  6:  MATERIALS  &  TESTING  INFORMATION  SYSTEMS 


Information  System 

M 

B 

S 

T 

A 

I 

Aggregate  Certification 

4 

H 

M 

1 

H 

H 

Material  Sample  Management 

3 

H 

M 

2 

H 

H 

Independant  Assurance  System 

4 

H 

M 

1/2 

H 

H 

Site  Inspector  Assignment 

2 

L 

L 

1/2 

L 

L 

Test  Reports 

3 

H 

M 

2 

H 

H 

Material  Analysis 

2 

M 

L 

4 

H 

L 

Payroll 

1 

- 

- 

- 

- 

- 

Vehicle  Control 

5 

L 

L 

1/2 

L 

L 

Requisition 

5 

M 

H 

1 

H 

H 

Inventory 

3 

M 

H 

1/2 

H 

H 

M  -  Mode  of  use:       1  =  No  automation  recommended 

2  =  Local  dedicated  CPU 

3  =  Local  DBMS  with  data  transfer 

4  =  Local  CPU  with  data  access 

5  =  Remote  data  input/access 

B  -  Backup  &  Recovery: 

S  -  Security: 

T- Time  of  use:  (hours  per  day) 

A  -  Auditability: 

I  -  Integrity  of  data: 

L  -  Low  concern 
M  -  Medium  concern 
H  -  High  concem 
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3.2.6  Subdistrict  Information  Systems 

The  subdistrict  is  the  most  visible  arm  of  the  IDOH.  They  repair  the  Indiana  road- 
ways, confirm  overweight/oversize  permits,  maintain  IDOH  vehicles,  plow  the  roads  dur- 
ing winter  storms,  and  help  plan  highway  improvement  projects.  The  subdistricis  are, 
therefore,  the  main  source  of  maintenance  data;  data  that  is  used  to  feed  several  impor- 
tant information  systems.  Automation  at  the  subdistrict  level  would  open  up  exciting 
new  information  system  applications,  and  is  highly  recommended.  Table  7  presents  a 
summary  of  important  factors  to  be  considered  in  automating  the  information  systems  of 
at  the  Sub-district  offices. 

As  computers  are  introduced  in  the  subdistrict  new  protocols  for  data 
entry/retrieval  should  be  made.  For  instance,  a  new  crew  day  card  system  should  be 
designed  to  allow  data  entry  to  be  made  daily  in  the  subdistrict  office.  This  information 
can  be  transmitted  to  the  district  and  central  offices,  and  can  be  used  to  generate  daily, 
weekly,  and  monthly  progress  reports.  These  data  could  also  be  used  to  feed  a  roadway 
history  system,  the  maintenance  management  system,  a  budget  planning  system,  a  pave- 
ment management  system,  and  many  more.  With  a  well  thought  out  local  DBMS  with 
data  transmittal  to  these  other  systems,  the  IDOH  would  be  well  on  it's  way  to  creating 
new  powerful  system  tools. 

Another  system  improvement  could  be  made  in  efficiently  automating  the 
oversize/overweight  permit  system.  Presently,  when  a  permit  is  requested,  the  subdistrict 
clerk  calls  central  office  to  check  on  road  closures  to  ensure  a  safe  route.  A  more 
efficient  system  would  allow  the  subdistrict  computer  to  call  the  central  office  computer 
at  an  obscure  time,  and  download  any  road  closure  information  to  the  local  subdistrict 
computer.  This  would  allow  all  permits  to  be  approved  at  the  subdistrict  office  and  avoid 
long  waits  for  the  issuance  of  the  permit.  In  this  case  data  are  controlled  by  the  central 
office  but  retrieved  by  the  subdistrict  CPU. 

While  backup  and  recovery  of  subdistrict  systems  is  an  issue,  it  is  the  most  impor- 
tant in  the  gas  and  parts  inventories.  Data  lost  here  can  lead  to  abuses  of  these  systems, 
and,  thus,  must  be  easily  recovered. 

Subdistrict  systems  are  not  security  risks.  Rather,  access  to  these  systems  are 
necessary  to  perform  many  district  and  central  office  tasks,  and  therefore  should  be  left 
open. 

With  distributed  data  entry  of  crew  day  cards,  the  time  required  per  subdistrict 
should  be  minimal  and  the  benefit  of  this  data  entry  effort  would  yield  daily  summaries, 
weekly  and  monthly  progress  reports  at  a  keystroke.  Queries  to  the  data  base  would 
allow  complex  analysis  of  subdistrict  performance  and  it  is  likely  that  subdistrict  person- 
nel may  choose  to  spend  additional  time  utilizing  these  new  capabilities. 

With  an  automated  permit  system,  it  would  be  necessary  to  have  a  CPU  accessible 
as  permit  applicants  enter  the  subdistrict  office.  While  it  is  not  necessary  that  a  unit  be 
dedicated  solely  to  permit  use,  it  should  be  recognized  that  this  system  take  priority  over 
other  subdistrict  systems,  so  that  permit  applicants  are  served  quickly.  It  is  estimated  that 
this  system  would  take  up  to  three  hours  maximum  per  day.   Two  computer  stations 
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Table  7:  SUBDISTRICT  INFORMATION  SYSTEMS 


Information  System 

M 

B 

S 

T 

A 

I 

Crew  Day  Cards 

3 

M 

L 

1 

M 

H 

Daily  Summary  Sheet 

3 

M 

L 

1/2 

M 

M 

Monthly  Report 

3 

M 

L 

1/2 

M 

M 

Permits 

4 

M 

M 

3 

H 

H 

Claim  Vouchers 

5 

M 

H 

1/2 

H 

H 

The  Central  Garage  Book 

1 

- 

- 

- 

- 

- 

Highway  Improvement  Program 

4 

L 

L 

1/2 

L 

M 

Inventory  Parts  &  Gasoline 

3 

M 

H 

2 

H 

H 

Payroll 

1 

- 

- 

- 

- 

- 

Vehicle  Control 

5 

L 

L 

1/2 

L 

L 

Requisitions 

5 

M 

H 

1 

H 

H 

Inventory 

3 

M 

H 

1/2 

H 

H 

M  -  Mode  of  use: 


1  =  No  automation  recommended 

2  =  Local  dedicated  CPU 

3  =  Local  DBMS  with  data  transfer 

4  =  Local  CPU  with  data  access 

5  =  Remote  data  Input/access 


B  -  Backup  &  Recovery: 

S  -  Security: 

T  -  Time  of  use:  (hours  per  day) 

A  -  Auditability: 

I-  Integrity  of  data: 

L  -  Low  concern 

M  -  Medium  concern 

H  -  High  concern 
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would  be  expected  to  be  able  to  handle  heavy  periods  with  one  being  sufficient  for  most 
days. 

There  are  several  subdistrict  systems  that  require  rigid  audiiability  features.  The 
permit  system,  claim  vouchers,  and  the  parts  and  gas  inventory  are  systems  that  cannot 
be  compromised.  Entries  and  deletions  must  be  made  by  approved  employees  only. 

Subdistricts  information  systems  in  which  data  integrity  is  a  primary  concern  is  the 
permit  system,  claim  vouchers,  the  parts  and  gas  inventory,  and  the  crew  day  card  sys- 
tem. The  integrity  of  the  crew  day  card  system  is  important  in  that  this  system  can  feed 
so  many  other  district  and  central  office  systems. 

3.2.7  Traffic  Information  Systems 

The  Traffic  Division's  responsibilities  include  the  response  to  signal  malfunctions, 
the  re-analysis  of  traffic  flow  patterns,  the  maintenance  of  traffic  signs,  and  the  annual 
repainting  of  the  highways.  Like  the  subdistrict  systems,  the  Traffic  Division  systems 
can  feed  and  support  many  district  and  central  office  systems.  A  synthesis  of  Traffic 
division  information  systems  automation  is  presented  in  Table  8. 

The  Traffic  Division  also  makes  use  of  the  crew  day  card  system  to  monitor  and 
plan  traffic  maintenance  systems.  This  system,  as  well  as  the  trouble  call  log,  and  the 
illumination  outage  summary  can  be  used  to  support  comprehensive  central  office  reports 
and  a  roadway  history.  The  best  modes  for  these  systems  would  be  a  local  DBMS  with 
data  transfer.  The  signal  inventory,  the  road  closure  log,  and  the  paint  records,  as  is  the 
case  for  all  other  inventories,  would  also  be  best  automated  using  a  local  DBMS  with 
data  transfer. 

Backup  of  traffic  systems  should  be  designed  to  occur  on  a  periodic  basis.  How- 
ever, this  is  not  a  major  design  factor. 

As  with  many  other  systems,  traffic  systems  should  be  available  for  study  by  dis- 
trict, subdistrict,  and  central  office  personnel.  The  system  should  be  designed  to  allow 
this  easy  access. 

Most  traffic  systems  need  only  be  updated  and  consulted  when  needed.  For  exam- 
ple, crew  day  cards  need  to  be  entered  daily,  but  with  disbursed  data  entry,  this  task  is 
minimal.  One  exception  would  be  with  the  roadway  investigation  system.  This  system 
is  an  engineering  function  and  would  require  an  intensive  dedicated  work  session. 

One  system  that  obviously  would  require  a  strong  auditability  feature  is  the  trouble 
call  log.  As  this  system  keeps  track  of  when  traffic  signals  malfunction  and  the  time  of 
response,  responsibility  for  the  call  and' for  the  recording  is  paramount 

Several  systems  require  a  strong  data  integrity  design.  The  crew  day  cards,  the  sig- 
nal inventory,  and  the  road  closure  log  all  must  be  consulted  at  different  locations  in  the 
IDOH  and  this  data  cannot  be  discordant. 
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Table  8:  TRAFFIC  INFORMATION  SYSTEMS 


Information  System 

M 

B 

S 

T 

A 

I 

Trouble  Call  Log 

3 

M 

L 

1 

H 

M 

Crew  Day  Cards 

3 

M 

L 

1 

M 

H 

Signal  Inventory 

3 

M 

L 

1/2 

M 

H 

Paint  Records 

3 

L 

L 

1/2 

L 

M 

Roadway  Investigations 

2 

L 

L 

4 

L 

L 

Road  Closure  Log 

3 

M 

M 

1/2 

M 

H 

Illumination  Outage  Summary 

3 

M 

M 

1/2 

M 

M 

Contract  Progressive  Estimate 

3 

M 

L 

1/2 

M 

L 

Payroll 

1 

- 

- 

- 

- 

- 

Vehicle  Control 

5 

L 

L 

1/2 

L 

L 

Requisition 

5 

M 

H 

1 

H 

H 

Inventory 

3 

M 

H 

1/2 

H 

H 

M  -  Mode  of  use: 


1  =  No  automation  recommended 

2  =  Local  dedicated  CPU 

3  =  Local  DBMS  with  data  transfer 

4  =  Local  CPU  with  data  access 

5  =  Remote  data  input/access 


B  -  Backup  &  Recovery: 

S  -  Security: 

T  -  Time  of  use:  (hours  per  day) 

A  -  Auditability: 

I-  Integrity  of  data: 


L  -  Low  concem 
M  -  Medium  concem 
H  -  High  concern 
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3.3  Automating  Existing  Information  Systems 

One  approach  to  the  automation  of  information  handling  and  management  at 
remote  IDOH  office  locations  would  be  to  develop  software  for  each  system  identified  in 
the  previous  section  consistent  with  the  guidelines  provided  by  the  profiles  for  each  sys- 
tem presented  in  the  Appendix  of  this  report  and  with  input  from  those  individuals  within 
IDOH  responsible  for  those  areas.  As  a  demonstration  of  this  concept  and  for  purposes 
of  this  report,  the  CREW  DAY  CARD  information  system  has  been  automated  using 
only  the  computer  technology  presented  earlier  in  Table  1  of  this  report.  Input  for  system 
design  was  provided  by  individuals  from  the  LaPone  and  Fort  Wayne  district  offices  for 
this  system  that  was  developed  using  the  PARADOX  relational  DBMS  software  pro- 
vided by  IDOH  Computer  Services  to  each  district  office.  For  a  complete  discussion  of 
the  development  and  intended  use  of  that  system  see: 

Stukel,  Gregory  R.,  Computer  Prototype  for  the  Maintenance  Manage- 
ment System  Crew  Day  Cards,  MS  Thesis,  School  of  Civil  Engineering, 
Purdue  University,  December,  1986. 

Based  on  the  experience  gained  through  this  exercise  and  a  previous  familiarity  with  the 
software  provided  by  this  configuration  (Table  1),  it  is  suggested  that  vinually  all  of  the 
information  systems  presented  in  this  study  could  be  automated  in  a  fashion  similar  to 
that  used  in  the  above  reference. 

3.4  Major  Problems  With  Automating  Existing  Systems 

The  strategy  of  automating  existing  information  systems  presents  some  severe 
problems,  both  practical  and  philosophical.  The  following  discussion  raises  some  of 
these  problems.  The  final  chapter  of  this  report — Chapter  4 — recommends  against  such 
an  approach  to  automation  in  favor  of  a  more  modem  and  realistic  method  to  achieve 
more  efficient  remote-office  automation. 

1.  Many  existing  systems  may  be  difficult  or  inefficient  to  automate.  Most  sys- 
tems were  designed  out  of  a  non-automated  environment  and  do  not  lend  them- 
selves to  efficient  automation.  For  instance,  automating  each  inventory  separately 
would  be  inefficient  and  difficult.  Similarly,  a  separate  winter  transfer  employee 
report  would  be  inefficient  as  data  entry  would  be  duplicated  by  crew  day  card  data 
entry  and  maintenance  management  data  entry. 

2.  Automating  existing  information  systems  Mould  result  in  an  overall  system 
that  would  be  difficult  to  support  and  maintain.  Presently  central  office  com- 
puter services  is  frequently  overwhelmed  by  user  questions  and  requests.  By 


One  small  omission  in  the  selection  of  software  provided  to  each  district  that  might  be  required  in  the 
future  if  such  a  course  of  action  is  taken  would  be  an  adequate  terminal  emulation  program  for  the 
personal  computers  and,  depending  on  the  condition  of  communiciiiion  lines,  a  modem  and  requisite 
communications  software. 
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increasing  the  number  of  diverse  systems,  the  task  of  maintaining  and  these  sys- 
tems would  be  impossible.  Several  instances  of  similar  applications  being  sup- 
poned  by  different  programs  and  data  sets  were  encountered  during  the  initial 
interviews  for  this  study. 

3.  Such  an  approach  might  result  in  distributed  data  as  well  as  distributed  pro- 
cessing. Distributed  processing  may  result  in  too  broad  a  range  in  the  distribution 
of  data,  particularly  if  different  districts  or  divisions  provide  specifications  for  their 
own  program  elements. 

4.  Such  a  system  would  be  difficult  to  expand  in  the  future.  A  concened  upgrade 
of  IDOH  systems  would  require  a  much  more  arduous  effort  Programmers  and 
engineers  would  be  required  to  be  familiar  with  several  systems,  and  coordinating 
these  systems  might  also  be  difficult. 

5.  Such  a  system  would  be  difficult  to  monitor  and  control.  Data  residing  within 
different  systems  would  be  difficult  to  aggregate  into  simple,  clear  computer  sys- 
tem repons.  Decisions  that  might  be  clear  with  a  complete  system  report  would  be 
veiled  when  system  data  are  disjoined.  Likewise,  it  would  be  difficult  to  find  and 
fix  system  security  breaches  with  many  different  systems. 

6.  Training  of  personnel  would  be  diiticult  and  would  probably  not  be  possible  in 
any  systematic  fashion.  Geating  many  diverse  systems  would  necessitate  that 
district  personnel  learn  several  unrelated  systems.  The  high  turnaround  of  district 
and  subdistrict  clerks  would  require  frequent  retraining  classes  and  create  a  void  in 
the  position  as  the  new  employee  would  be  forced  to  leam  and  master  many  sys- 
tems. 

7.  The  system  would  require  very  high  start-up  costs.  Designing  each  information 
system  separately  would  require  duplicate  programming  as  well  as  data  entry.  If 
systems  are  not  combined  much  time  and  effort  would  be  wasted  re-programming 
basic  program  modules. 

These  are  but  a  few  of  the  problems  that  might  be  encountered  in  attempting  to  use 
existing  non-automated  systems  as  designs  for  their  automated  counterpart.  To  make 
matters  worse,  many  individuals  interviewed  during  the  course  of  this  study  questioned 
whether  those  systems  actually  worked  as  they  should  and  expressed  the  concern  that 
automating  those  systems  would  make  things  considerably  worse.  Even  choosing  a  few 
major  systems  would  require  a  great  deal  of  effort  and  input  on  the  part  of  a  few  key 
engineering  personnel  and  it  would  not  be  clear  how  their  normal  workload  might  be 
covered  during  such  an  exercise. 

Thus  far,  we  have  attempted  to  show  that  the  benefits  from  automating  remote- 
office  information  management  can  be  enormous,  but  that  using  existing  information  sys- 
tems as  goals  of  such  an  effort  might  prove  futile  or,  at  least  extremely  expensive.  In  a 
more  theoretical  vein,  there  is  no  reason  to  expect  that  information  systems  that  have 
evolved  over  time  without  automation  technology  would  be  even  close  to  optimal  in  a 
fully  automated  environment.  It  is  fair  to  say  that  drastic  changes  in  this  type  of  thinking 
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are  necessary  to  bring  the  level  of  office  automation  within  IDOH  up  to  today's  stan- 
dards. The  final  chapter  presents  some  recommendations  to  help  achieve  this  goal. 
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4.  FURTHER  RECOMMENDATIONS 


While  the  scope  of  this  research  has  been  limited  to  remote  office  locations,  it  has 
become  clear  that  a  comprehensive  analysis  of  information  systems  in  those  offices 
requires  a  detailed  look  at  the  role  of  central  office  information  and  data  requirements  is 
needed  as  well  as  an  understanding  of  the  physical  and  logical  interface  between  the  two 
systems.  In  addition,  it  is  important  to  understand  to  what  degree  the  present  capital 
investment  in  compute  capability  at  the  central  office  imposes  constraints  on  remote 
office  automation.  As  a  result,  the  recommendations  that  follow  must  be  qualified  by  the 
fact  that  revolutionary  changes  to  the  present  protocols  for  data  storage,  handling  and 
management  might  not  be  possible  in  view  of  these  constraints.  The  analysis  of  central 
office  computing  was  beyond  the  mandate  of  this  study  and  is  best  left  to  the  IDOH  staff 
responsible  for  that  system. 

It  has,  however,  also  become  clear  that  revolutionary  changes  in  the  way  that  infor- 
mation is  managed  throughout  IDOH  would  result  in  significant  improvements  in  the 
level  of  service  offered  to  the  residents  of  Indiana.  Indeed,  if  all  of  the  activities  dis- 
cussed in  the  previous  chapter  were  automated  to  the  appropriate  level,  the  increase  in 
overall  operations  efficiency  and  quality  of  service  would  be  dramatic.  As  important, 
revolutionary  changes  are  needed  to  bring  IDOH  remote  office  information  management 
practices  to  the  point  where  they  can  benefit  from  future  advances  in  office  automation 
technology  that  are  sure  to  come. 

This  chapter  offers  some  ideas  for  this  type  or  radical  change  throughout  IDOH 
both  in  terms  of  the  physical  computer  support  system  and,  to  a  much  lesser  degree,  the 
administration  of  that  system.  While  the  recommendations  might  seem  drastic  at  first 
glance,  it  is  suggested  that  much  of  the  hardware  and  software  required  to  achieve  many 
of  these  changes  are  presently  in  place  within  IDOH.  The  most  difficult  obstacles  to 
overcome  would  be  resistance  to  change  on  the  part  of  those  who  would  benefit  most 
from  that  change! 

Three  major  recommendations  are  offered:  1)  consolidate  the  84  separate  informa- 
tion systems  discussed  in  the  previous  chapters  of  this  report  into  a  smaller  number — 
nine  are  suggested — of  more  comprehensive  information  systems  each  having  a  distinct 
data  structure;  2)  increase  the  staff  of  the  Data  Services  Division  to  include  computer 
systems  administrators  at  remote  offices  to  handle  hardware  and  software  issues  and  con- 
duct user  training;  3)  promote  a  base  of  user  support  by  offering  mechanisms  for  user 
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input  to  software  design  and  future  system  expansion.  Each  of  these  recommendations  is 
discussed  below. 


4.1  Consolidating  IDOH  Information  systems 

The  most  important  recommendation  of  this  report  is  that  the  IDOH  work  toward  a 
goal  of  a  high  level  of  remote  office  automation.  To  promote  this,  the  present  informa- 
tion systems  should  be  both  automated  and  also  redesigned.  This  redesigning  cffon 
should  be  directed  toward  data  structures  that  encompass  the  present  information  systems 
as  well  as  new  ambitious  systems  to  assure  that  valuable  information  that  could  be  util- 
ized to  support  statewide  decisions  is  not  wasted.  Nine  separate  but  related  data  base 
systems  are  proposed: 

4 

1.  Accounting 

2.  Communications 

3.  Engineering 

4.  Equipment  Management 

4 

5.  Maintenance  Management  and  Plannmg 

6.  Personnel 

7.  Project  Management  and  Planning 

8.  Resource  Management  and  Inventory 

9.  Roadway  Inventory  and  History 

The  considerations  outlined  in  the  information  system  tables  are  still  relevant,  and 
should  be  designed  into  these  new  systems,  as  most  information  from  the  former  systems 
will  still  be  required.  Other  design  requirements  are: 

•  All  systems  should  be  user  friendly  and  menu  driven. 

•  Use  of  codes  (such  as  material  and  vendor  codes)  should  be  avoided. 

•  The  design  of  every  system  should  be  an  interactive  process  between  the  system 
users  and  software  engineers. 

•  Each  system  should  have  automatic  data  entry  error  checking. 

•  Whenever  p)ossible,  data  being  sent  to  the  central  office  computer  should  be 
entered  locally,  and  transmitted  during  slower  evening  hours.  This  would  allcNiatc 


Significant  systems  exist,  or  are  being  developed  in  these  areas  presently  at  the  IDOH  central  office  but 
the  degree  to  which  these  systems  (particularly  the  Administration  system)  incorporate  distributed 
processing  or  data  management  is  unknown. 
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the  problem  of  slow  entry  screens,  and  lighten  the  central  office  computer  load. 

An  appropriate  level  of  distributed  data  should  be  achieved  together  with  distri- 
buted processing.  Insuring  that  delays  in  using  information  are  due  to  processing 
rather  than  data  access  should  be  the  guiding  goal  in  determining  the  appropriate 
level  of  distributed  data  storage. 


1.  The  Accounting  System  .  ■_  ,  ^ 

A  single  accounting  system  should  be  created  and  automated  with  utility  bill 
management,  payroll  records  and  vouchers,  petty  cash,  requisitions,  and  claim 
vouchers  incorporated.  Information  should  continue  to  flow  as  it  does  now;  district 
and  subdistrict  requisition  requests  should  be  routed  to  central  office  via  district 
administration.  These  requests  should  be  automated  with  district  administration 
checking  and  compiling  the  requests  and  forwarding  these  to  central  office. 

As  a  result  of  this  effort,  the  subdistrict  office,  the  district  office,  and  the  cen- 
tral office  should  be  able  to  generate  running  budget  updates,  and  general  account- 
ing reports,  as  well  as  the  ability  to  perform  complex  database  queries. 

2.  The  Communications  System 

The  planning  and  scheduling  of  highway  projects  need  to  be  integrated  with  the 
many  ongoing  highway  activities.  Road  paving  and  repainting  need  to  be  coordi- 
nated, as  an  example.  What  is  required  is  a  highway  "project  calendar"  and  elec- 
tronic "mail  and  message"  program.  Communications  are  very  easily  automated, 
and  would  be  a  great  benefit  of  overall  office  automation. 

A  complete  inter/intra  office  communications  network  could  be  designed. 
Included  in  this  network  would  be  an  electronic  mail/message  and  calendar  system. 
It  will  be  important  that  a  protocol  for  updating  this  system  be  enforced,  as  every 
district  and  subdistrict  activity  should  be  entered  in  the  calendar  and  consulted  reg- 
ularly. With  this  system  in  place  and  actively  employed,  conflicting  projects  can 
be  successfully  scheduled,  and  the  problem  of,  say,  repaving  a  road  soon  after 
painting,  or  installing  expensive  raised  pavement  markings  may  be  avoided.  This 
would  be  a  sound  IDOH  investment. 

A  direct  application  of  this  system  would  be  in  the  area  of 
oversized/overweight  permits.  Road  closure  announcements  could  be  mailed 
through  the  Communication  System  from  central  office  and  stored  locally  in  the 
subdistrict  office.  This  would  speed  up  the  issuance  of  permits,  as  verification  of 
safe  routes  could  be  made  locally. 

3.  The  Engineering  Library 

A  library  of  engineering  software  should  be  available  to  all  personnel  in  the  district 
offices.  There  should  be  an  avenue  open  to  request  the  purchase  of  new  software; 
and  any  new  software  purchased  should  be  globally  available  to  all  district  person- 
nel.   Several  engineering  systems  were  requested  by  district  personnel.    These 
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include: 

•  A  comprehensive  surveying  package 

•  Signal  timing  optimization  software 

•  A  complete  material  expert  system  and  calculation  package 

•  Land  parcel  acquisition  optimization  software 

•  Snow  plow  routing  optimization  software 

•  Paint  vehicle  routing  software 

•  Barrow  pit  calculation  software 

•  Software  to  retrieve  traffic  counts  from  electric  counting  boards 

•  Traffic  sign  upgrade  scheduler 

•  General  purpose  CAD/CAE  software 

4.  The  Equipment  Management  System 

The  Preventive  Management  System  should  be  expanded  to  include  all  equipment 
that  requires  regular  maintenance.  This  system  should  also  be  controlled  at  the  dis- 
trict Maintenance  Division,  so  that  system  performance  is  improved  and  informa- 
tion more  timely.  As  communication  is  important  to  this  system,  it  would  be  wise 
to  use  this  system  as  an  input  to  the  Communications  System.  Maintenance 
notices  can  be  sent  via  electronic  mail  to  the  responsible  department  in  the  district 
or  subdistrict,  and  regular  system  reports  can  be  made  to  central  office. 

5.  Maintenance  Management  and  Planning 

Each  of  the  many  maintenance  management  systems  need  to  be  consolidated  into  a 
single  comprehensive  automated  system.  Careful  attention  should  be  given  to  the 
relationships  between  information  required  and  provided  by  the  Crew  Day  Card 
System,  the  Bridge  Log,  the  Paint  Record  System,  the  Winter  Transfer  Reporting 
System,  the  Highway  Improvement  Program,  the  Pavement  Management  System, 
and  the  present  Maintenance  Management  System, 

This  consolidated  system  would  take  as  input  information  from  all  crew  day 
cards,  paint  records,  fatal  accident  reports,  the  trouble  call  log,  and  pavement 
management  to  plan  the  next  years  schedule,  subdistrict  planning  would  be 
improved  by  automated  repons  that  would  allow  the  check  of  scheduled  progress 
versus  actual  progress  for  daily  activities.  As  with  other  systems,  complex  data- 
base queries  could  be  made  on  a  routine  basis,  even  across  databases. 

6.  The  Personnel  System 

Presently,  the  State  Personnel  system  limits  district  and  subdistrict  administrators 
to  information  of  primary  interest  to  the  central  office.  All  information  is  carried 
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on  a  single  sheet  of  computer  output.  Furthermore,  the  present  system  information 
is  updated  using  a  courier  and  the  preprinted  computer  form.  With  additional  dis- 
trict automation  it  would  be  possible  to  create  a  personnel  "inventory",  owned  and 
controlled  by  each  district  office.  This  system  could  be  customized  to  include  pay- 
roll information,  safety  records,  affirmative  action  reports,  as  well  as  special  train- 
ing information.  Each  administrator  should  be  allowed  to  personalize  his  system, 
and  perform  complex  database  queries. 

7.  Project  Management  and  Planning 

A  complete  Project  Management  and  Planning  System  should  be  designed  to 
encompass  many  of  the  Construction  and  Material  and  Test  Systems.  Included  in 
the  Project  Management  and  Planning  System  would  be  the  Daily,  Weekly,  and 
Monthly  reports,  all  contract  and  subcontract  systems.  Inspector  Assignment,  Con- 
tract Correspondence,  Material  Test  Reports,  the  Highway  Improvement  Program, 
Material  Sample  Management,  Material  Test  Reports,  Aggregate  Certification,  and 
the  Contractor  Performance  (and  insurance)  Reports.  This  system  would  allow 
fingertip  access  to  any  project  information  required  by  the  IDOH  Offices. 

Ideally,  this  system  would  allow  a  user  to  retrieve  information  such  as;  a  list 
of  all  ongoing  projects;  the  monthly,  weekly  or  daily  repons  for  any  project;  the 
materials  and  suppliers  being  used  on  any  project;  the  contract  and  subcontracts; 
the  H.I.P.  schedules;  contractor  insurance  and  performance  reports;  and  the 
expected  schedules  for  any  projects;  and  other  more  complex  queries. 

8.  Resource  Management  and  Inventory 

The  Resource  Management  and  Inventory  System  would  serve  to  manage  expend- 
able resources,  such  as  gasoline,  spare  parts,  paint,  and  other  materials. 

9.  Roadway  Inventory  and  History 

A  most  important  addition  to  IDOH  systems  would  be  the  Roadway  Inventory  and 
History  System.  Properly  automated,  this  system  would  allow  maintenance  per- 
sonnel keystroke  access  to  information  on  all  aspects  of  present  and  past  roadway 
conditions.  This  capability  would  provide  a  quantitative  basis  for  the  planning  and 
managing  of  maintenance  activities  and  would  contribute  to  future  pavement 
management  programs. 

Included  in  the  inventory  would  be  the  description  and  the  locations  of  all 
state  highways,  bridges,  billboards,  driveways,  signals,  overpasses,  road  markings, 
signs,  etc.  This  data  would  be  supplemented  with  the  history  of  the  roadway, 
including; 

•  Major  Construction  and  Maintenance  Contracts 

•  Fatal  Accident  Reports 
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•  Road  Test  Data 

•  Daily  Traffic  Signal  Maintenance 

•  Daily  Roadway  Maintenance 

At  present  all  information  required  for  such  a  system  is  being  collected  and  stored, 
in  some  form.  While  automating  these  systems  it  will  be  important  to  allow  for  the 
extraction  of  relevant  information  so  that  the  data  can  be  sent  to  the  Roadway 
Inventory  and  History. 

The  single  greatest  source  of  information  into  this  system  will  be  the  Crew 
Day  Card.  This  source  of  infonmation  is  a  "diary"  of  maintenance  and  traffic 
activities;  they  record  all  maintenance  activities  as  they  occur  and  fttd  all  mainte- 
nance planning  systems. 

Similar  to  the  Maintenance  and  Traffic  Crew  Day  Cards,  is  the  Construction 
and  Maintenance  contract  histories,  in  that  all  construction  activities  are  being 
recorded  through  the  Daily  Reports.  Included  in  the  present  system  is  the  progress 
of  the  project  as  well  as  materials  and  equipment  used.  Channeled  properly,  this 
information  would  be  invaluable  to  the  Roadway  Inventory  and  History-. 

There  does  not  presentiy  exist  any  comprehensive  means  for  storing  or 
retrieving  this  information  or  tying  this  information  to  road  segment  location.  This 
problem  will  need  to  be  addressed,  as  the  previously  discussed  benefits  of  this  sys- 
tem far  outweigh  any  startup  or  maintenance  costs. 

4.2  Systems  Administration 

There  is  a  need  for  a  person  knowledgeable  in  computer  hardware  and  software 
development  in  each  district.  This  system  administrator  would  be  responsible  for 

•  Becoming  familiar  with  district  and  subdistrict  hardware  and  software  systems. 

•  Educating  district  and  subdistrict  personnel  in  the  use  of  these  systems. 

•  Becoming  familiar  with  every  district  and  subdistrict  Information  System. 

•  Software  development  of  district  and  subdistrict  systems. 

•  Monitoring  and  controlling  all  district  and  subdistrict  hardware  and  software  sys- 
tems. 

The  system  administrator  should  always  be  available  for  questions  from  district 
and  subdistrict  personnel.  With  this  source  close  to  the  system  users,  learning  a  new  sys- 
tem would  take  less  time  and  would  be  more  easily  mastered,  similarly,  as  the  System 
administrator  becomes  more  familiar  with  how  district  and  subdistrict  tasks  are  per- 
formed, new  efficient  systems  can  be  recommended  and  developed  with  more  informed 
district  and  subdistrict  input 
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It  will  be  necessary  that  each  System  Administrator  report  directly  to  the  District 
Engineer,  and  not  central  office  or  the  district  Administrative  Manager.  The  System 
Administrator  should  be  both  the  district  and  subdistrict  "advocate"  to  central  office,  and 
also  be  above  the  confines  of  district  "politics". 

It  will  also  be  important  to  schedule  periodic,  say  bi-weekly,  meetings  of  all  Sys- 
tem Administrators.  These  meetings  would  serve  to  standardize  all  new  systems,  as  well 
as  organize  possible  shared  development.  Time  should  be  spent  discussing  upgrades  to 
system  hardware  configurations,  and  new  developments  in  computer  technologies. 


4.3  User  Community 

The  IDOH  should  work  toward  a  goal  of  having  a  computer  educated  work  force. 
District  and  subdistrict  employees  should  be  encouraged  to  educate  themselves  in  com- 
puter software  and  hardware,  and  to  learn  the  capabilities  of  any  system,  so  that  they  can 
suggest  or  implement  improvements  to  these  systems. 

The  benefits  of  a  "computer  education  program"  would  be  great,  district  personnel 
could  play  a  vital  role  in  shaping  the  new  systems,  as  well  as  the  systems  of  the  future. 
By  allowing  district  and  subdistrict  input  into  new  system  designs,  computer  hesitancy 
would  be  erased  and  systems  would  be  better  designed. 
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DIVISION:  Administration 

SYSTEM:  InvGntofy  Management 

PURPOSE: 

The  purpose  of  the  inventory  management  system  is  to  control  and  record 
all  equipment  assets  in  the  districts  and  subdistricts.  This  information  is 
used  for  central  office  audits.  Information  included  in  the  inventory  are  the 
status  of  maintenance  and  construction  equipment,  furniture,  vehicles, 
spare  parts,  etc... 

DESCRIPTION: 

The  inventory  listing  is  a  computer  generated  printout  containing  the 
expected  inventory  of  each  division  within  the  district  and  subdistrict.  A  new 
inventory  listing  is  usually  distributed  annually  and  is  often  long,  not  accu- 
rate and  not  timely. 

INFORMATION  FLOW: 

The  computer  generated  print-out  is  sent  to  the  district  from  the  central 
office  every  year.  District  administration  divides  and  distributes  the  inven- 
tory to  the  corresponding  district  division  or  subdistrict  for  comparison  with 
actual  inventories.  The  administration  collects  and  sends  the  inventory 
corrections  to  the  central  office. 

CENTRAL  OFFICE  INTERFACE: 

The  central  office  uses  this  information  to  keep  an  up  to  date  record  of  the 
inventory  for  each  of  the  districts  and  subdistricts.  The  central  office  keeps 
the  official  inventory. 

EXISTING  FORMS:  None. 

REMARKS: 


DIVISION:  Administration 

SYSTEM:  Aff irmativG  Action  Reports 

PURPOSE: 

Affirmative  action  reports  are  completed  for  federal  and  state  government 
agencies.  These  reports  monitor  all  affirmative  action  programs  in  the  dis- 
trict and  are  used  for  statistical  information  and  to  ensure  compliance  with 
state  and  federal  hiring  guidelines. 

DESCRIPTION: 

Affirmative  action  reports  are  originated  by  the  administrative  manager 
every  year.  The  report  details  in-house  minority  grievances  and  complaints, 
as  well  as  logs  minority  construction  contracts  awarded.  Each  instance  a 
minority  is  interviewed  for  possible  employment  must  be  logged  and  must 
include  all  details  of  the  interview,  such  as  who  performed  the  interview  and 
the  outcome  of  the  interview. 

INFORMATION  FLOW: 

The  affirmative  action  reports  are  compiled  by  the  administrative  manager 
and  forwarded  to  the  central  office. 

CENTRAL  OFFICE  INTERFACE: 

The  central  office  receives  the  reports  and  fonA/ards  them  to  the  federal  and 
state  equal  employment  agencies. 

EXISTING  FORMS:  None. 

REMARKS: 


DIVISION:  Administration 

SYSTEM:  Utility  Bill  Management 

PURPOSE: 

The  purpose  of  the  utility  bill  management  system  is  to  process  and  moni- 
tor all  utility  bills  (eg.  gas,  phone,  water,  etc..) 

DESCRIPTION: 

The  district  administrative  manager  receives  bills  from  the  utilities,  checks 
the  bills  for  mistakes  and  rationalizes  long  distance  phone  calls.  The  bills 
are  then  paid  through  the  Requisition  System. 

INFORMATION  FLOW: 

The  administrative  manager  receives  a  copy  of  the  bill  from  the  utility  com- 
pany. He  may  contact  any  section  heads  to  verify  any  questionable  bills. 
After  the  bill  is  reviewed,  a  requisition  form  is  sent  to  the  central  office  to 
cover  the  cost  of  the  bill.  The  central  office  then  issues  the  check. 

CENTRAL  OFFICE  INTERFACE: 

The  central  office  receives  and  reviews  the  utility  bill  and  rationalizes  any 
extraordinary  bill.  They  will  issue  the  checks  for  payment  of  the  bills. 

EXISTING  FORMS:  None. 

REMARKS: 


DIVISION:  Administration 
SYSTEM:  Safety  Records 


PURPOSE: 

The  purpose  of  the  safety  record  is  to  keep  an  accurate  account  of  all 
employee  accidents  or  injuries.  This  information  is  recorded  for  insurance 
investigations,  proper  awarding  of  compensation,  future  training,  policy 
corrections  and  possible  litigation. 

DESCRIPTION: 

The  safety  records  are  primarily  recorded  on  two  forms.  For  vehicle  and 
equipment  accidents  State  Form  39697  is  used.  The  information  included 
on  this  form  is  a  description  of  the  accident,  parties  involved,  equipment  or 
vehicle  involved,  date,  location,  weather  conditions,  time  of  day,  damage 
estimate,  property  damage  if  any,  insurance  company  and  witnesses. 

For  job  injuries,  State  Form  34401  is  used.  This  form  includes  information 
regarding  the  nature  of  the  accident,  cause  of  the  injury,  time,  place, 
employee,  employer,  estimated  time  off  for  compensation,  lost  workdays, 
etc. 

INFORMATION  FLOW: 

The  injured  wori<er  fills  out  the  report  and  sends  it  to  the  unit  foreman  for 
review.  A  copy  of  the  report  is  circulated  to  the  general  foreman,  the  sub- 
district  clerk,  the  district  safety  director,  the  administrative  manager, 
insurance  representatives,  and  finally  the  central  office. 

CENTRAL  OFFICE  INTERFACE: 

The  central  office  compiles  all  reports  and  makes  a  yearly  report  by  dis- 
trict. 

EXISTING  FORMS: 

State  Form  39697  - 

vehicle  &  equipment 

accident  report 

State  Form  34401  -  report  of  injury  to  employee 

REMARKS: 


DIVISION:  Administration 
SYSTEM:  Pefsonnel  Records 


PURPOSE: 

The  purpose  of  the  personnel  record  is  to  keep  a  concise,  up  to  date  file  of 
each  employee. 

DESCRIPTION: 

Employee  Information  is  kept  in  an  alphabetized  individual  file.  The  file  con- 
tains employee  addresses,  salary  action,  job  description,  date  of  employ- 
ment, emergency  information,  accident  reports,  etc...  Access  to  the  person- 
nel file  is  controlled  and  usually  consists  of  the  district  engineer,  administra- 
tor and  administration  secretaries. 

INFORMATION  FLOW: 

Any  additions  to  the  file  can  be  made  at  the  district  or  central  office.  Merit 
raise  lists  are  sent  to  the  district  from  the  central  office  to  be  checked. 
Updates  in  the  personnel  record  are  performed  using  state  form  25616,  and 
by  sending  this  form  to  the  centra!  office. 

CENTRAL  OFFICE  INTERFACE: 

The  central  office  keeps  the  records  updated  by  communicating  via  state 
form  25616.  Note  that  this  system  is  used  for  all  state  employees  and  is  not 
limited  to  the  IDoH. 

EXISTING  FORMS:  State  Form  25616  Employee  Profit  Non-merit 

REMARKS: 

Administrators  feel  additional  information  should  be  added  to  the  file  and 
could  be  kept  with  the  district  administrator. 


DIVISION:  Administration 
SYSTEM:  FugI  InvGntopy 


PURPOSE: 

The  purpose  of  the  fuel  inventory  system  is  to  adnninister  the  dispensing  of 
fuel  at  the  districts  and  subdistricts.  This  information  is  used  for  central 
office  audits  and  to  check  pumping  equipment.  For  example,  if  the  morning 
tank  reading  is  off  from  the  previous  day's  reading,  there  may  either  be  a 
leak  in  the  tank  or  unauthorized  usage. 

DESCRIPTION: 

When  fuel  is  dispensed,  the  pump  operator  logs  the  amount  dispensed,  and 
this  total  should  correspond  with  periodic  pump  readings.  Mileage  is  moni- 
tored for  each  vehicle  and  checked  for  reasonable  usage.  The  administra- 
tion director  uses  this  information  for  semi-annual  inventory  updates  and 
central  office  audits. 

INFORMATION  FLOW: 

As  the  employee  fills  up  their  vehicles'  fuel  tank,  the  gallon  amount  of  fuel, 
the  vehicle  type,  the  vehicle  number  and  the  employee,  are  recorded.  Tank 
outflow  is  measured  and  rationalized  with  tank  inflow  by  a  maintenance  staff 
member.  Fuel  required  is  sent  to  the  central  office  via  a  PTD  form  and  the 
district  IBM  3276  terminal. 

CENTRAL  OFFICE  INTERFACE: 

After  receiving  the  information  from  the  PTD  forms,  via  the  IBM  3276  termi- 
nal, a  computer  printout  of  the  information  is  made  and  checked  for  errors. 
This  printout  is  then  sent  back  to  the  district  where  it  is  used  to  check  input 
of  errors. 

EXISTING  FORMS:  State  Form  38851 R 
PTD  Form 

REMARKS: 


DIVISION:  Administration 
SYSTEM:  Petty  Cash  Reports 


PURPOSE: 

The  petty  cash  report  serves  to  monitor  petty  cash  expenditures. 

DESCRIPTION: 

The  petty  cash  report  lists  petty  cash  expenditures  along  with  the  reasons 
for  the  purchases.  Petty  cash  purchases  are  limited  to  $50.00. 

INFORMATION  FLOW: 

The  reports  are  mailed  to  the  central  office. 

CENTRAL  OFFICE  INTERFACE: 

Central  office  reconciles  costs  and  reimburses  the  subdistrict  so  the  $200 
petty  cash  fund  is  always  filled. 

EXISTING  FORMS:  None. 

REMARKS: 


DIVISION:  Administration 
SYSTEM:  Payroll  Records 


PURPOSE: 

The  purpose  of  the  payroll  record  is  to  maintain  an  accurate  record  of 
employee  payroll  and  pay  status,  and  also  to  keep  track  of  benefits  such  as 
sick  days  and  merit  raises.  This  information  is  used  by  administration  to 
give  merit  raises  and  also  to  answer  employee  questions  involving  vacation 
time,  sick  days,  and  next  raise  consideration. 

DESCRIPTION: 

Employees  fill  out  their  individual  pay  vouchers.  These  are  collected  and 
reviewed  by  the  general  foreman  in  the  subdistricts  and  division  clerks  in 
the  districts.  Pay  voucher  information  includes  hours  worked  and  vacation 
or  sick  days  taken. 

INFORMATION  FLOW: 

The  vouchers  are  reviewed  and  compiled  by  the  administrative  secretary 
then  mailed  to  the  central  office.  The  central  office  issues  checks  which  are 
hand  carried  to  the  district  offices. 

CENTRAL  OFFICE  INTERFACE: 

The  central  office  is  responsible  for  issuing  all  pay  checks,  and  for  keeping 
a  record  of  employee  sick,  vacation,  and  personal  days. 

EXISTING  FORMS:  None. 

REMARKS: 


DIVISION:  Construction 

SYSTEM:  Monttily  Project  Report 

PURPOSE: 

The  monthly  project  report  is  a  record  of  the  progress  of  the  contracted 
constnjction  project.  Its  purpose  is  to  inform  the  central  office  of  the 
monthly  progress  of  the  construction  project. 

DESCRIPTION: 

The  monthly  project  report  is  compiled  for  each  contracted  project.  The 
report  contains  general  information  such  as  the  location  of  construction, 
the  general  progress,  weather  conditions,  reasons  for  delays,  and  an 
estimate  of  the  completion  date. 

INFORMATION  FLOW: 

The  monthly  progress  report  is  compiled  by  the  project  engineer.  A  copy 
of  the  monthly  progress  is  mailed  to  the  district  from  the  project  engineer. 
The  original  is  sent  to  the  central  office. 

CENTRAL  OFFICE  INTERFACE: 

All  monthly  progress  reports  are  reviewed  at  the  central  office. 

EXISTING  FORMS:  Form  I.C.1 17  State  Form  2323 

REMARKS: 

This  form  is  important  to  track  the  progress  of  the  contract  and  to  docu- 
ment the  different  stages  of  construction  as  well  as  any  unusual  prob- 
lems. The  monthly  progress  report  should  also  note  the  anticipated  start- 
ing dates  of  major  operations  and  document  road  openings  and  closing. 


DIVISION:  Construction 

SYSTEM:  Final  Construction  Record 

PURPOSE: 

The  purpose  of  the  final  construction  record  is  to  document  the  history  of 
the  contracted  job.  The  final  constnjction  record  is  used  for  updating 
road  and  bridge  logs  and  for  documenting  the  closing  of  the  contract. 
The  final  constnjction  record  also  documents  all  material  sample  tests, 
communications,  and  extensions  in  case  of  future  legal  matters. 

DESCRIPTION: 

The  final  constnjction  record  is  compiled  by  the  project  engineers  and 
includes  an  accounting  of  all  project  expenditures  based  upon  a  unit  price 
basis.  The  record  documents  all  results  of  material  sample  tests  as  well 
as  material  used.  The  record  also  contains  the  contract  extensions  and 
remarks  and  the  Contract  Completion  Report. 

INFORMATION  FLOW: 

The  project  engineer  keeps  all  pertinent  information  involving  the  contract 
during  the  lifetime  of  that  contract  including  daily,  weekly,  and  monthly' 
reports.  At  the  completion  of  the  project,  the  project  engineer  will  com- 
pile this  information  into  the  final  construction  record  which  is  reviewed 
by  the  district  construction  engineer.  The  reviewed  final  construction 
record  is  submitted  to  the  Central  Office  for  their  review  and  preparation 
of  the  final  payment  to  the  contractor. 

CENTRAL  OFFICE  INTERFACE: 

The  original  final  construction  record  is  sent  to  the  central  office. 

EXISTING  FORMS:  CRz,  PR47,  IC733,  IC639,  IC686,  IC126,  M232. 
M232A.  IC225,  IC644,  IC608,  IC115,  IC626,  IC642,  IC654,  IC632,  IC601 

REMARKS: 


DIVISION:  Construction 

SYSTEM:  Contfact  Correspondence 

PURPOSE: 

The  purpose  of  the  contract  correspondence  system  is  to  keep  a  per- 
manent record  of  all  communication  with  contractors  for  each  project. 

DESCRIPTION: 

Contract  Correspondence  is  a  written  record  of  all  communications  and 
contact  between  the  contractor,  state,  subcontractor,  and  vendors,  etc... 
It  includes  important  telephone  notes,  letters,  etc... 

INFORMATION  FLOW: 

All  correspondence  concerning  the  project  are  sent  to  the  district  office. 
This  includes  any  correspondence  between  project  engineer  and  contrac- 
tor, project  manager  or  district  head.  It  also  includes  information  con- 
cerning material  testing  and  subcontractors.  The  correspondence  is  kept 
in  the  open  contract  file  and  later  is  incorporated  into  the  Final  Construc- 
tion Record. 

CENTRAL  OFFICE  INTERFACE: 
None 

EXISTING  FORMS:  None 

REMARKS: 


DIVISION:  Construction 

SYSTEM:  Extfa  WofK  Agreoments 

PURPOSE: 

The  extra  work  agreement  is  a  contract  for  necessary  work  that  was  not 
included  in  the  original  contract. 

DESCRIPTION: 

The  extra  work  agreement  is  a  description  of  what  the  extra  work  is,  an 
estimate  as  to  what  extra  materials  will  be  needed,  and  a  projected  cost. 

INFORMATION  FLOW: 

If  a  contractor  or  the  project  engineer  feel  there  is  warrant  for  additional 
work,  or  a  contract  change,  the  district  construction  engineer  is  notified, 
and  a  contract  may  be  written.  The  contract  is  then  sent  for  approval  to 
the  central  office. 

CENTRAL  OFFICE  INTERFACE: 

The  central  office  reviews  all  extra  work  agreements.  The  review  pro- 
cess may  be  lengthened  by  the  amount  of  the  additional  work. 

EXISTING  FORMS:  None. 

REMARKS: 


DIVISION:  Construction 
SYSTEM:  Daily  Reports 


PURPOSE: 

The  purpose  of  the  daily  report  is  to  give  a  daily  account  of  the  progress 
on  every  project.  It  is  the  diary  of  the  project. 

DESCRIPTION: 

The  daily  report  records  information  concerning  employee  hours  and  per- 
sonnel for  the  project.  It  describes  what  equipment  was  used  on  the  con- 
struction project,  the  weather  conditions,  and  all  pay  items  for  the  project 
for  that  day. 

INFORMATION  FLOW: 

The  daily  report  is  compiled  by  the  project  engineer  and  sent  to  the  Dis- 
trict Construction  Engineer  via  the  mail  or  hand  delivery.  This  information 
is  then  stored  in  the  open  construction  project  file.  The  original  daily 
report  is  retained  in  the  District  file  indefinitely  and  the  project  engineer's 
file  copy  Is  sent  to  the  Central  Office  with  the  final  construction  record. 

CENTRAL  OFFICE  INTERFACE: 

Project  engineer's  copy  is  sent  to  Central  Office  with  the  final  constmc- 
tion  record. 

EXISTING  FORMS:  IC1 03  and  IC224 

IC1 03  for  construction  contracts  ,    ,  .. 

IC224  for  bridge  construction  contracts 

REMARKS: 


DIVISION:  Construction 

SYSTEM:  Contfact  Completion  Reports 

PURPOSE: 

The  contract  completion  report  documents  the  completion  of  a  contracted 
constnjction  project.  The  report  signifies  acceptance  of  the  project  and 
serves  as  impetus  for  final  payment  to  the  contractor. 

DESCRIPTION: 

The  contract  completion  report  is  a  record  of  a  completed  contracted 
constnjction  project. 

INFORMATION  FLOW: 

Upon  the  satisfactory  completion  of  a  project,  the  project  engineer  com- 
pletes the  contract  completion  report  and  sends  it  to  the  district  office. 
The  district  review  officer  reviews  the  form  and  prepares  a  cover  letter  for 
the  district  construction  engineer  and  the  district  engineer.  Copies  of  the 
report  go  to  the  district  file  and  are  entered  into  the  final  construction 
record.  Final  payment  is  made  after  District  and  Central  Offices  review 
the  contract  completion  report. 

CENTRAL  OFFICE  INTERFACE: 

The  central  office  receives  and  reviews  a  copy  of  the  contract  completion 
report.  They  then  may  issue  a  letter  of  acceptance,  thereby  relieving  the 
contractor  of  site  maintenance. 

EXISTING  FORMS:  IC639  &  IC686 

REMARKS: 


DIVISION:  Construction 
SYSTEM:  Subcontracts 


PURPOSE: 

There  is  a  standard  procedure  for  approving  subcontractors.  This  sys- 
tem serves  to  enforce  this  procedure. 

DESCRIPTION: 

The  standard  specifications,  article  108.01  state  that  the  contractor  have 
written  authority  to  sublet  a  portion  of  the  work.  Form  IC730  serves  as 
approval  notification  and  is  issued  out  of  the  central  office. 

INFORMATION  FLOW: 

The  prime  contractor  submits  the  request  to  the  district  for  subcontractor 
approval.  The  district  reviews  the  request  and  forwards  it  to  the  Central 
Office  for  approval. 

CENTRAL  OFFICE  INTERFACE: 

The  Central  Office  may  request  information  from  the  districts  or  vice 
versa.  The  Central  Office  reviews  all  subcontractor  requests. 

EXISTING  FORMS:  IC730,  CM32-34,  MBE-2 

REMARKS: 


DIVISION:  Construction 

SYSTEM:  Contractof  Performance 

PURPOSE: 

The  purpose  of  the  contractor  performance  list  is  to  maintain  a  record  of 
all  IDoH  certified  contractors. 

DESCRIPTION: 

This  list  includes  a  history  of  previous  contracts,  and  maximum  liability 
and  the  insurance  expiration  date,  for  every  IDoH  certified  contractor. 
The  prequalification  engineer  uses  this  information  as  an  acceptable  con- 
tractor list. 

INFORMATION  FLOW: 

The  form  Is  prepared  by  the  project  engineer,  reviewed  by  the  area 
engineer  and  district  constnjction  engineer  and  sent  to  the 
prequalification  engineer  in  the  Central  Office.  Only  one  form  is  made  - 
no  copies  kept.  One  form  is  prepared  for  each  contractor  and  subcon- 
tractor. 

CENTRAL  OFFICE  INTERFACE: 

EXISTING  FORMS:  CR-2 

REMARKS: 

This  is  an  extremely  important  document  to  aid  in  establishing  a  contrac- 
tors ability  to  perform  certain  types  of  work. 


DIVISION:  Construction 

SYSTEM:  InspGCtof  AssJgnment 

PURPOSE: 

The  purpose  is  to  assign  inspectors  to  appropriate  inspection  sites. 

DESCRIPTION: 

Constnjction  is  responsible  for  assigning  site  inspectors  to  the  project 
sites.  The  criteria  is  usually  based  on  the  proximity  of  the  site  to  the 
inspector's  home. 

INFORMATION  FLOW: 

All  information  is  maintained  by  the  district  or  area  engineer. 

CENTRAL  OFFICE  INTERFACE: 
none 

EXISTING  FORMS:  None 

REMARKS: 

The  inspectors  need  to  be  assigned  where  they  will  be  used  to  the  best 
advantage  to  the  state.  Consideration  must  be  given  to  home  location, 
work  location,  transportation,  type  of  work,  type  of  experience  of  inspec- 
tor, reliability  of  inspector,  and  location  of  other  qualified  inspectors. 


DIVISION:  Construction 

SYSTEM:  Weekly  Project  Reports 

PURPOSE: 

The  purpose  of  the  weekly  project  report  is  to  maintain  a  convenient  esti- 
mate of  the  project's  current  status  for  the  district  construction  engineer. 

DESCRIPTION: 

The  weekly  project  report  is  usually  one  page  long  and  briefly  describes 
the  activities  at  a  project  site.  The  weekly  project  report  is  compiled  by 
the  project  engineer,  and  is  a  general  overview  of  the  week's  daily 
reports.  It  is  reviewed  by  the  district  engineer  and  documents  time 
remaining  on  the  contract. 

INFORMATION  FLOW: 

The  weekly  project  report  is  compiled  by  the  project  engineer  from  the 
daily  reports.  These  weekly  reports  are  reviewed  at  the  constnjction 
engineer's  leisure  as  a  general  overview  at  a  contracted  projects  pro- 
gress. The  original  is  sent  to  the  contractor  for  his  disposition  and  infor- 
mation. 

CENTRAL  OFFICE  INTERFACE: 
Central  Office  receives  a  copy. 

EXISTING  FORMS:  Weekly  Project  Reports  10124 

REMARKS: 


DIVISION:  Development 
SYSTEM:  Roadljfe  Log 


PURPOSE: 

The  purpose  of  the  road  life  is  to  maintain  a  current  history  of  the  road- 
way. The  information  in  this  log  is  used  for  design  investigations,  intero- 
gatories,  and  general  historical  information.  The  log  records  each  large 
repair  or  major  maintenance  construction  contract.  This  contract  informa- 
tion can  then  be  used  for  follow  up  studies,  contractor  performance,  and 
any  future  litigation. 

DESCRIPTION: 

The  road  life  log  is  a  file  kept  in  the  district  office.  A  separate  file  is  kept 
at  the  central  office.  The  district's  file  is  categorized  by  county  &  road.  A 
section  of  roadway  is  displayed  and  a  chronological  history  of  all  major 
improvements  on  any  part  of  that  section  are  defined  and  noted.  Other 
parameters  included  in  the  log  are  the  date  finished,  project  number, 
major  material,  surface  type,  cost  and  geographical  limits  of  the  project. 
Typically,  the  roadway  history  dates  back  to  when  the  road  was  incor- 
porated into  the  state  highway  system,  or  when  the  road  was  originally 
const  njcted. 

INFORMATION  FLOW: 

After  the  final  construction  record  is  completed,  a  copy  is  loaned  to  the 
development  area  for  proper  updating  of  the  road  life  log.  The  informa- 
tion is  then  stored  in  the  log  until  needed. 

CENTRAL  OFFICE  INTERFACE: 

None,  unless  litigation  dictates  a  need  for  the  information.  The  central 
office  compiles  their  own  history  of  the  roadway. 

EXISTING  FORMS: 

REMARKS: 

The  present  roadway  log  is  not  complete  or  detailed.  By  creating  a  com- 
plete comprehensive  roadway  history  that  includes  all  small  roadway  or 
signal  maintenance,  accidents,  and  sign  maintenance,  IDOH  could  have 
a  powerful  pavement  management,  inventory,  and  legal  tool. 


DIVISION:  Development 
SYSTEM:  Bridge  Log 


PURPOSE: 

The  purpose  of  the  bridge  log  is  to  keep  a  record  of  bridge  inspections. 
This  includes  the  bridge's  location,  the  next  scheduled  inspection,  a 
description  of  the  latest  maintenance  and  contracts.  This  information 
system  is  mandated  by  the  Federal  government,  and  is  also  used  in  the 
possibility  of  litigation. 

DESCRIPTION: 

The  bridge  log  is  categorized  by  state  road  and  county,  and  is  currently 
kept  in  a  file.  The  bridge  log  records  all  structures  over  20  feet  long. 
Copies  of  all  bridge  inspections  are  kept  in  the  file.  Bridge  inspections 
are  administered  through  the  maintenance  department. 

INFORMATION  FLOW: 

All  maintenance  work  must  be  recorded  by  the  development  engineer 
who  then  records  the  information  into  the  bridge  file.  Bridges  are  main- 
tained and  inspected  by  the  maintenance  division,  who  report  all  mainte- 
nance activities  to  the  development  engineer. 

CENTRAL  OFFICE  INTERFACE: 

The  central  office  administers  their  own  bridge  log,  through  the  bridge 
inspection  reports. 

EXISTING  FORMS:  None. 

REMARKS: 


DIVISION:  Development 
SYSTEM:  Pepmits 


PURPOSE: 

The  permit  office  at  the  district  office  issues  all  commercial  and  private 
driveway  permits. 

DESCRIPTION: 

The  permit  engineer  approves  ail  private  drives  in  the  district,  v^hile  com- 
mercial driveways  are  jointly  approved  by  the  district  permit  engineer  and 
the  central  office.  The  permit  inspector  physically  reviews  plans  and  sub- 
mits information  to  the  traffic  engineer  to  be  cooordinated  with  other  IDoH 
improvements. 

INFORMATION  FLOW: 

The  permit  inspector  physically  reviews  all  plans  and,  after  consulting 
with  the  traffic  engineer,  may  recommend  issuance  of  the  permit.  The 
recommendations  are  sent  to  the  central  office  for  final  approval. 

Some  projects  require  review  by  federal  and  state  agencies.  These 
agencies  may  request  any  information  concerning  the  project  including 
plans  and  drawings.  All  permits  issued  are  stored  at  the  central  office. 

CENTRAL  OFFICE  INTERFACE: 

Central  office  may  review  larger  projects  and  send  copies  of  these  pro- 
jects to  federal  agencies. 

EXISTING  FORMS:  None. 

REMARKS: 


DIVISION:  Development 
SYSTEM:  BHIboard  Inventory 


PURPOSE: 

The  billboard  inventory  is  mandated  by  the  federal  government  in  accor- 
dance with  the  Highway  Beautification  Act.  The  purpose  of  the  billboard 
inventory  is  to  have  an  updated  list  of  all  billboards  on  state  roadways. 

DESCRIPTION: 

The  billboard  inventory  is  a  list  of  each  billboard  that  is  erected  within 
federally  mandated  regulations.  The  list  is  in  the  form  of  a  computer  prin- 
tout generated  at  the  central  office.  The  inventory  is  categorized  by  state 
road. 


INFORMATION  FLOW: 

Twice  a  year  the  central  office  sends  a  computer  generated  list  of  what 
billboard  is  located  on  each  state  road.  Development  physically  checks 
the  accuracy  of  this  printout  by  sending  a  crew  to  each  billboard  location. 
Additions  and  deletions  are  made  to  the  inventory.  Any  additions  to  the 
inventory  are  checked  to  ensure  the  billboard  is  within  regulations.  If  the 
billboard  is  not,  the  district  sends  a  notice  to  the  owner  requesting  the 
structure  be  dismantled.  If  the  owner  does  not  act  within  14  days,  the 
central  office  will  issue  a  notice.  After  the  inventory  has  been  checked, 
the  corrections  are  sent  to  the  central  office. 

CENTRAL  OFFICE  INTERFACE:  .         ,.    . 

Two  copies  of  the  printout  are  sent  to  the  district  development  office. 
One  copy  is  used  in  the  field  where  updates  are  made.  Those  updates 
are  then  transferred  to  the  second  copy  and  sent  to  the  central  office. 
The  information  is  manually  copied  off  the  printout  and  put  onto  individual 
computer  forms.  These  forms  are  them  given  to  the  computer  operator 
to  be  typed  onto  the  system. 

EXISTING  FORMS:  None. 

REMARKS: 


DIVISION:  Development 

SYSTEM:  Railfoad  Crossing  Inventory 

PURPOSE: 

The  purpose  of  the  railroad  crossing  inventory  Is  to  monitor  the  physical 
condition  of  each  railroad  crossing. 

DESCRIPTION: 

The  railroad  crossing  inventory  is  done  yearly.  Information  Included  In 
the  inventory  are  a  history  of  the  crossing,  the  type  of  railroad  crossing, 
advanced  warning  signs,  pavement  markings  and  their  condition,  signal 
lights,  and  number  of  tracks. 

INFORMATION  FLOW: 

The  railroad  crossing  Inventory  originates  at  the  central  office.  This 
Inventory  Is  sent  to  the  district  development  office  once  a  year.  At  the 
district,  the  Inventory  is  updated  and  sent  back  to  the  central  office  for 
distribution. 

CENTRAL  OFFICE  INTERFACE: 

Two  copies  of  the  printout  are  sent  from  the  central  office  to  the  district. 
One  copy  Is  updated  In  the  field,  then  these  updates  are  carefully 
transferred  to  the  second  printout.  It  is  this  second  printout  that  Is  sent  to 
the  central  office. 

EXISTING  FORMS:  None 

REMARKS: 


DIVISION:  Development 
SYSTEM:  SuTvey  Operations 


PURPOSE: 

The  purpose  of  having  a  survey  party  in  the  district  development  office  is 
for  staking  construction  projects,  checking  deeds,  reestablishing  right  of 
ways,  preparing  parcels  of  state  owned  property  for  public  sales,  etc... 

DESCRIPTION: 

Survey  operations  are  conducted  by  a  licensed  surveyor  and  one  survey 
crew.  The  crew  is  controlled  through  the  development  office,  and  work  is 
scheduled  by  project  priority.  The  crew  has  a  backlog  of  projects,  that 
require  both  field  work  and  courthouse  research. 

INFORMATION  FLOW: 

The  district  development  office  is  notified  by  the  central  office  of  parcels 
that  may  be  bought  or  sold  and  that  require  surveys.  Also  construction  or 
maintenance  may  notify  development  that  a  project  may  require  a  sur- 
vey. Surveys  are  performed  and  the  the  survey  information  is  sent  to  the 
interested  parties. 

CENTRAL  OFFICE  INTERFACE: 

Central  office  requests  surveys  be  done,  and  appropriate  information 
returned. 


EXISTING  FORMS:  None 
REMARKS: 


DIVISION:  Development 
SYSTEM:  Desigpi  Operations 


PURPOSE: 

The  districts  perform  design  within  development.  This  usually  is  small 
designs  such  as  turning  lanes  etc.  Draftsmen  are  used  by  development 
for  intersection  design  and  layout. 

DESCRIPTION: 

The  design  and  drawing  is  carried  out  by  a  development  design  engineer 
and  draftsmen. 

INFORMATION  FLOW: 

If  the  design  of  a  project  is  within  the  District's  capabilities,  central  office 
will  OK  the  design.  Development  coordinates  these  new  projects  with 
input  from  the  other  district  sections  and  the  subdistricts. 

CENTRAL  OFFICE  INTERFACE: 
The  central  office  approves  all  projects. 

EXISTING  FORMS:  None 

REMARKS: 


DIVISION:  Development 
SYSTEM:  Publlc  InforiTiation 


PURPOSE: 

There  is  a  need  to  inform  the  public  and  utilities  of  upcoming  scheduled 
constRjction  projects  and  road  closures.  This  information  is  required  for 
schools,  emergency  vehicles,  news  agencies,  and  public  utilities. 

DESCRIPTION: 

Information  is  sent  via  letter  or  telephone.  The  development  engineer 
keeps  a  list  of  all  newspapers,  radio  stations,  agencies  that  must  receive 
this  information.  All  the  impending  detours  and  road  closings  resulting 
from  projects  planned  in  the  H.I. P.,  and  regular  maintenance  are  closely 
monitored. 

INFORMATION  FLOW: 

The  project  engineer  should  give  the  development  engineer  and  traffic 
engineer  a  two  week  notice  as  to  what  projects  will  require  road  closures. 
It  is  development's  responsiblity  to  notify  the  news  agencies  and  radio 
stations  within  the  immediate  area.  The  information  is  also  sent  to  the 
Central  Office. 

CENTRAL  OFFICE  INTERFACE: 

Central  office  usually  keeps  this  information  for  issuing  permits. 

EXISTING  FORMS:  None 

REMARKS: 


DIVISION:  Development 
SYSTEM:  Right  of  Way  Control 

PURPOSE: 

The  purpose  for  right  of  way  control  is  to  maintain  an  active  inventory  of 
right-of-way  documents,  to  prepare  documents  and  plats  for  road  relinqu- 
ishments and  surplus  property,  and  to  provide  an  inventory  of  elevation 
benchmarks  throughout  District. 

DESCRIPTION: 

The  maintenance  of  files  and  release  of  requested  documents  is  the 
responsibility  of  the  development  engineer. 

INFORMATION  FLOW: 

If  the  data  requested  is  available  in  the  district  office,  the  development 
engineer  may  release  the  information.  If  additional  data  is  needed,  a 
request  may  be  submitted  to  the  central  office  for  the  information. 

CENTRAL  OFFICE  INTERFACE: 

The  central  office  keeps  information  of  interest  to  the  district  development 
engineer,  and  may  be  asked  to  provide  such  information. 


REMARKS: 


DIVISION:  Maintenance 

SYSTEM:  Pfeventlve  Maintenance 

PURPOSE: 

The  purpose  of  the  Preventive  Maintenance  system  is  to  equip  and  force 
regular  maintenance  on  all  vehicles  in  the  IDOH. 

DESCRIPTION: 

The  system  keeps  track  of  mileage  on  vehicles,  and  hours  on  equipment. 
When  regular  maintenance  is  required,  the  responsible  employee  is 
notified  to  take  the  equipment  to  the  maintenance  shop. 

INFORMATION  FLOW: 

Monthly,  employees  fill  out  the  equipment  usage  log  with  relevant  infor- 
mation (mileage,  usage,...).  These  are  sent  to  Indianapolis  and  entered 
into  the  computer.  When  it  is  time  for  regular  maintenance  (oil  change, 
tune  up,  etc.)  a  PM  work  order  is  sent  to  the  responsible  employee  who 
takes  the  equipment  to  the  shop. 

If  during  maintenance  further  work  is  required,  a  repair  work  order  form  is 
filled  out  and  the  work  completed. 

CENTRAL  OFFICE  INTERFACE: 

Central  office  monitors  all  vehicles  and  manages  all  information. 

EXISTING  FORMS:  None. 

REMARKS: 


DIVISION:  Maintenance 
SYSTEM:  Cfew  Day  Card 


PURPOSE: 

The  purpose  of  the  crew  day  card  is  to  compile  and  put  into  readable 
fornn  daily  subdistrict  activities  and  productivity. 

DESCRIPTION: 

The  District  acts  as  the  compiler  of  all  crew  day  cards.  They  have  little 
input,  but  act  as  the  central  office  keypunch. 

INFORMATION  FLOW:  , 

The  subdistricts  send  the  crew  day  cards  and  monthly  reports  to  the  Dis- 
trict. The  district  clerk  compiles  all  relevant  information  and  enters  this 
into  the  Central  Office  Computer. 

CENTRAL  OFFICE  INTERFACE: 

Central  office  uses  this  information  to  plan  for  the  next  year's  work. 

EXISTING  FORMS:  None. 

REMARKS: 


DIVISION:  Maintenance 

SYSTEM:  Winter  Transfer  Report 

PURPOSE: 

This  report  is  a  legal  document  which  outlines  precautions  taken  by  the 
IDOH  for  snow  plow  route  coverage. 

DESCRIPTION: 

At  the  end  of  each  nnonth,  maintenance  compiles  this  report  and  files  it 
with  the  Central  Office.  The  report  contains  a  daily  log  of  which  employ- 
ees were  assigned  to  each  snowplow  route.  This  changes  daily  when 
employees  quit/are  hired.  The  report  takes  a  lot  of  time  and  is  very 
thorough. 

INFORMATION  FLOW: 

The  maintenance  engineer  keeps  a  close  daily  tab  on  employee  cover- 
age of  routes  in  the  district,  and  fills  out  the  report  daily.  At  the  end  of  the 
winter  the  report  is  sent  to  the  Central  Office. 

CENTRAL  OFFICE  INTERFACE: 
Central  office  store  the  reports. 

EXISTING  FORMS:  None. 

REMARKS: 


DIVISION:  Maintenance 

SYSTEM:  BuildinQ  &  Grounds  Inventory 

PURPOSE: 

The  purpose  of  the  inventory  is  to  keep  a  record  of  all  IDOH  owned  struc- 
tures. 

DESCRIPTION: 

The  building  and  grounds  superintendent  inspects  and  inventories  all 
structures  (excluding  bridges)  and  contracts  building  maintenance.  The 
inventory  includes  the  worth  of  the  structure,  the  condition  of  the  struc- 
ture, and  necessary  improvements. 

INFORMATION  FLOW: 

The  building  and  grounds  superintendent  inspects  all  stnjctures  (parks, 
weigh  stations  included)  and  reports  the  inventory  to  the  central  office 
yearly. 

CENTRAL  OFFICE  INTERFACE: 

Central  office  collects  information. 

EXISTING  FORMS:  None. 
REMARKS: 


DIVISION:  Maintenance 

SYSTEM:  Bhdge  Inspection  Log 

PURPOSE: 

The  purpose  of  the  bridge  inspection  log  is  to  keep  an  updated  report  of 
the  condition  of  all  the  bridges  in  the  district. 

DESCRIPTION: 

The  bridge  inspection  log  is  kept  on  a  standardized  "report  card"  with 
relevant  information  about  the  condition  of  each  bridge.  At  each  inspec- 
tion photographs  are  taken  and  sent  to  Indianapolis  for  developing.  A 
copy  of  the  latest  photos  are  kept  in  the  log. 

INFORMATION  FLOW: 

The  bridge  inspection  team  (one  in  every  district)  must  inspect  every 
bridge  at  least  once  every  2  years.  A  copy  of  the  report  is  sent  to  Indi- 
anapolis. This  file  is  used  to  recommend  bridge  maintenance  for  the 
HIP. 

The  central  office  will  remind  the  district  if  inspections  exceed  the  2  year 
period.  The  bridge  inspection  report  is  used  to  verify  compliance  with 
federal  guidelines. 

CENTRAL  OFFICE  INTERFACE: 
The  central  office  monitors  the  system. 

EXISTING  FORMS:  1.2 

REMARKS: 


DIVISION:  Maintenance 
SYSTEM:  Management  System 

PURPOSE: 

The  purpose  of  the  maintenance  management  system  is  to  plan  and 
monitor  the  yearly  maintenance  activities  of  all  Districts  and  Subdistricts. 

DESCRIPTION: 

The  maintenance  management  system  plans  acceptable  levels  of  work 
one  year  in  advance.  This  plan  is  specific  and  generally  accurate.  The 
plan  is  sent  to  the  districts  and  monitored  through  completed  Crew  Day 
Cards. 

INFORMATION  FLOW: 

One  year  in  advance,  subdistrict  superintendents  and  District  Mainte- 
nance engineers  estimate  expected  activity  time  requirements  based  on 
the  previous  year's  performance  and  knowledge  of  roadway  expansion. 
This  is  discussed  with  Central  Office  engineers  and  compared  with  the 
Crew  Day  Cards.  From  these  meetings,  the  Central  Office  budgets  the 
following  year's  maintenance  and  gives  guidelines  to  acceptable  levels  of 
work  via  Crew  Day  Cards.  The  Crew  Day  Cards  are  filled  out  daily  by 
the  subdistricts  and  compared  with  the  estimated  performance.  Large 
discrepancies  are  discussed. 

CENTRAL  OFFICE  INTERFACE: 

The  central  office  compiles  all  data  for  planning  next  year's  activities. 

EXISTING  FORMS:  MM-103,  MM-109.  MAMMs-180,  MM-311 

REMARKS: 


DIVISION:  Maintenance 

SYSTEM:  PaveiTient  Management 

PURPOSE: 

The  purpose  of  the  pavement  management  system  is  to  plan  for  the 
repavement  of  the  district's  roads. 

DESCRIPTION: 

When  the  subdistrict  superintendent  notices  excessive  maintenance  on  a 
section  of  road  (i.e.  potholes),  the  road  will  be  put  in  the  H.I. P.  for  a 
resurfacing  contract. 

INFORMATION  FLOW: 

The  district  will  voice  the  problem  via  the  H.I.P. 

CENTRAL  OFFICE  INTERFACE: 

The  central  office  decides  which  projects  are  to  be  funded. 

EXISTING  FORMS:  None. 

REMARKS: 
None 


DIVISION:  Subdistrict 
SYSTEM:  CfGW  Day  Cards 


PURPOSE: 

The  crew  day  card  is  part  of  the  maintenance  management  system. 
Crew  day  cards  serve  as  a  record  of  daily  crew  activity  information  such 
as  equipment  used,  location  of  activity,  work  accomplished,  personnel 
involved,  and  their  hours.  A  remarks  section  is  included  on  the  cards  for 
any  extraordinary  information.  These  cards  are  used  for  compiling  the 
daily  summary  sheets  and  the  monthly  productivity  list. 

DESCRIPTION: 

The  maintenance  management  system  is  a  planned  schedule  that  ori- 
ginates at  the  central  office.  The  subdistrict  superintendent,  the  general 
foreman,  the  unit  foreman,  and  district  maintenance  personnel  help  dev- 
ise the  details  of  this  schedule  every  two  weeks.  The  result  of  this  plan  is 
the  issuance  of  preprinted  crew  day  cards.  Each  card  comprises  one 
specific  planned  activity  such  as  mowing  and  patching.  This  card  is 
taken  by  the  crew  leader  on  each  activity  assignment  in  the  field,  and  the 
appropriate  information  is  recorded. 

INFORMATION  FLOW: 

Each  crew  generates  one  or  more  crew  day  cards  per  day.  The  units 
pass  the  completed  cards  to  the  subdistrict  where  it  is  passed  to  the  dis- 
trict and,  finally,  to  the  central  office.  At  the  subdistrict  the  crew  day  card 
information  is  transferred  to  a  mm-331  sheet  and  posted  every  week. 
This  information  is  then  transferred  to  a  maintenance  and  management 
control  work  sheet  every  month.  This  work  sheet  shows  the  subdistricts' 
progress  compared  with  their  semi-annual  schedule.  At  the  district,  infor- 
mation is  taken  off  the  crew  day  card  and  entered  into  the  IBM  3276  ter- 
minal. After  approximately  one  year,  the  crew  day  cards  are  sent  back  to 
the  district  where  they  are  stored. 

CENTRAL  OFFICE  INTERFACE: 

The  crew  day  card  information  is  sent  to  the  central  office  via  the  IBM 
3276  terminal,  and  is  used  for  scheduling  future  work.  The  central  office 
receives  information  from  the  terminal,  as  well  as  the  crew  day  cards 
themselves. 

EXISTING  FORMS:  Crew  Day  Cards 


Subdistrici    Crew  Day  Cards 


REMARKS: 

The  subdistrict  at  Vincennes  process  an  average  of  eight  to  ten  cards  a 
day.  After  a  year,  the  central  office  sends  the  cards  back  to  the  district 
where  they  are  stored  for  approximately  five  years.  Crev/  day  cards  are 
administered  through  the  maintenance  department  crew  day  cards. 

Most  district  maintenance  engineers  do  not  need  to  see  the  crew 
day  cards.  The  district  office  serves  only  to  keypunch  the  cards  and 
check  activity  codes,  etc... 


DIVISION:  Subdistrict 

SYSTEM:  Dally  SuiTimary  Sheet 

PURPOSE: 

The  purpose  of  the  daily  summary  sheet  is  to  keep  a  daily  record  of  all 
maintenance  activities.  This  information  is  used  for  compiling  a  monthly 
report  (mm-31 1)  which  acts  as  a  summarization  of  all  subdistrict  work. 

DESCRIPTION: 

The  daily  summary  is  compiled  from  crew  day  cards  and  includes  per- 
sonnel, equipment,  location  of  activity,  etc... 

INFORMATION  FLOW: 

The  monthly  summary  is  required  to  gage  the  productivity  of  the  subdis- 
trict, and  the  daily  summary  is  used  primarily  to  compile  this  report.  Gen- 
erally, only  the  subdistrict  secretary  uses  the  daily  summary  and  only  for 
compiling  the  mm  31 1  report. 

CENTRAL  OFFICE  INTERFACE: 

This  information  Is  later  transferred  to  the  maintenance  and  management 
control  worksheet. 

EXISTING  FORMS:  Work  Control  Worksheet 

REMARKS: 


DIVISION:  Subdistrict 
SYSTEM:  Mofithly  Repoft 


PURPOSE: 

The  purpose  of  the  Monthly  Report  (or  Productivity  List)  is  to  compare 
completed  activities  versus  scheduled  activities.  This  information  can 
then  be  used  for  future  scheduling  (scheduling  is  planned  every  two 
weeks),  to  rate  a  subdistricts  progress,  or  expose  any  problems. 

DESCRIPTION: 

The  monthly  report  is  processed  at  the  subdistrict  every  month,  and  is 
compiled  using  information  from  the  daily  summary  sheets.  The  list  com- 
pares the  subdistrict's  work  progress  with  the  monthly  plan  and  annual 
goals.  If  requested,  this  information  can  then  be  reviewed  by  the  subdis- 
trict superintendent,  district  maintenance  personnel,  central  office  per- 
sonnel, subdistrict  crew  leaders  and  workers. 

INFORMATION  FLOW: 

The  information  from  the  daily  summary  sheets  are  put  onto  the  monthly 
report  (mm  31 1  sheet).  This  information  can  then  be  posted  and 
accessed  by  any  employee.  A  copy  of  this  report  is  sent  to  the  central 
and  district  offices. 

CENTRAL  OFFICE  INTERFACE: 

The  central  office  uses  this  report  to  monitor  subdistrict  service. 

EXISTING  FORMS:  Work  Control  Worksheet 
Maintenance  Management  System 
Form  No.  MM-329    State  Form  2052 
(Division  of  Maintenance  Semi-Monthly  Schedule) 

REMARKS: 


DIVISION:  Subdistrict 
SYSTEM:  Pefmits 


PURPOSE: 

The  purpose  of  the  subdistrict  permit  system  is  to  allow  the  public  a  con- 
venient site  for  oversize/overweight  permits,  and  to  route  these  vehicles 
safely  through  the  state  highway  system. 

DESCRIPTION: 

Oversized  vehicles  must  have  a  permit  to  use  the  state  highways.  The 
permit  includes  a  route  that  the  vehicle  must  take,  and  the  hours  and 
date  allowed  for  the  trip. 

INFORMATION  FLOW: 

If  a  oversized  vehicle  Is  to  be  driven  in  the  state,  a  permit  must  be 
requested  at  the  subdistrict  office.  The  subdistrict  clerk  will  check  if  the 
proposed  route  is  acceptable  by  contacting  central  office,  where  an 
update  of  statewide  road  closures  is  kept.  Central  office  will  check  for 
road  closures  and  give  a  new  route  if  the  proposed  route  is  unaccept- 
able. The  clerk  will  accept  payment  and  issue  the  permit. 

CENTRAL  OFFICE  INTERFACE: 

Central  office  keeps  account  of  all  road  closures  for  the  state  on  the  cen- 
tral office  computer.  They  accept  and  reject  all  permits  through  the  sub- 
district  clerk. 

EXISTING  FORMS: 

REMARKS: 

Permits  are  issued  while  the  permitee  waits.  This  process  can  take  time 
as  the  central  office  gets  bogged  down  with  requests.  Subdistrict  person- 
nel feel  that  speeding  up  this  process  would  lead  to  better  public  percep- 
tion of  the  IDOH. 


DIVISION:  Subdistrict 
SYSTEM:  Claim  Vouchers 


PURPOSE: 

The  claim  voucher  is  a  means  of  paying  bills.  When  the  subdisthd  gets 
a  utility  bill,  they  send  in  a  claim  voucher  to  the  central  office.  The  central 
office  replies  by  sending  payment  for  the  bill. 

DESCRIPTION: 

The  claim  voucher  is  no  more  than  a  form  requesting  payment  of  a  bill. 

INFORMATION  FLOW: 

The  utility  will  send  the  subdistrict  a  bill.  The  subdistrict  will  then  send 
out  a  claim  voucher  to  the  central  office  to  request  payment.  The  central 
office  will  then  issue  the  check. 

CENTRAL  OFFICE  INTERFACE: 

All  claim  vouchers  go  to  the  central  office  and  all  checks  come  out  of  the 
central  office  for  payment  of  these  bills. 

EXISTING  FORMS:  Claim  Voucher 

REMARKS: 


DIVISION:  Subdistrict 

SYSTEM:  The  Central  Garage  Book 

PURPOSE: 

The  purpose  of  the  central  garage  book  is  to  maintain  a  catalog  of  avail- 
able items  In  each  subdistrict  stockroom. 

DESCRIPTION: 

The  central  garage  book  is  issued  through  the  central  office.  The  book 
contains  the  minimal  number  of  inventory  stock  items  that  each  subdis- 
trict stockroom  may  requisition  from  the  central  garage. 

INFORMATION  FLOW: 

The  compilation  of  the  central  garage  book  is  made  jointly  by  district  and 
central  office  personnel. 

CENTRAL  OFFICE  INTERFACE: 

The  central  garage  book  is  a  product  of  the  central  office. 

EXISTING  FORMS:  Central  Garage  Book 

REMARKS: 


DIVISION:  Subdistrict 

SYSTEM:  HighwHy  Improvement 

PURPOSE: 

The  Highway  Improvement  Program  is  a  means  to  explore  possible  ave- 
nues for  highv^ray  improvement  and  to  assign  and  fund  approved  projects 
for  the  program. 

DESCRIPTION: 

The  HIP  is  a  ten  year  highway  improvement  schedule.  Improvements  are 
recommended  and  accepted  based  on  need  and  budget.  This  schedule 
is  in  a  constant  state  of  flux  as  the  roadway  conditions  and  traffic  patterns 
change. 

INFORMATION  FLOW: 

Each  district  and  each  subdistrict  makes  recommendations  for  possible 
roadway  improvements.  The  recommended  projects  are  described  and 
prioritized.  Central  office  reviews  all  projects  statewide  and  enters  many 
into  the  ten  year  plan  based  on  need  and  budget  limitations.  Once 
accepted  and  scheduled,  the  means  are  provided  to  fund  and  construct 
the  project. 

CENTRAL  OFFICE  INTERFACE: 

Central  office  takes  care  of  all  budgeting  and  letting  of  contracts. 

EXISTING  FORMS:  None. 

REMARKS: 


DIVISION:  Subdistrict 

SYSTEM:  Invefitory  for  Parts  and  Gas 

PURPOSE: 

This  system  keeps  track  of  the  parts  and  the  gasoline  inventory  at  the 
subdistrict. 

DESCRIPTION: 

This  inventory  is  constantly  monitored  via  the  PTD  (parts  transition  docu- 
ments). Parts  requested  from  the  stockroom  at  the  subdistrict  are 
entered  on  a  PTD  Form.  Gasoline  is  allotted  at  the  subdistrict  and  again 
the  information  is  recorded  on  a  PTD  Form. 

INFORMATION  FLOW: 

Since  the  gasoline  and  equipment  inventories  change  rapidly,  the  daily 
flow  of  parts  are  monitored  using  the  PTD  Forms.  The  PTD  Forms  are 
keypunched  into  the  central  office  computer  at  the  districts.  Monthly  phy- 
sical inventories  are  performed  to  verify  the  PTD  generated  central  office 
inventory. 

CENTRAL  OFFICE  INTERFACE: 

The  central  office  monitors  via  the  IBM  terminal  and  the  district  office. 
Every  year  a  complete  parts  inventory  is  sent  from  the  central  office  to 
every  subdistrict  to  verify  the  expected  subdistrict  stock. 

EXISTING  FORMS:  State  Form  2639R3 

REMARKS: 


DIVISION:  Materials  &  Testing 
SYSTEM:  Aggregate  Certification 

PURPOSE: 

The  purpose  of  aggregate  certification  is  to  maintain  a  consistent  and 
quality  source  of  materials  for  all  state  highway  projects. 

DESCRIPTION: 

There  are  four  types  of  certifications.  The  first  type  of  certification  test  is 
an  annual  test  and  certifies  the  potential  quality  of  a  stone  quarry. 

The  second  type  of  certification  is  also  for  stone  quarries,  however, 
these  tests  are  performed  every  three  months,  and  the  test  certifies  the 
quality  of  materials  of  regularly  used  sites. 

The  third  aggregate  certification  for  stone  quarries  is  performed 
when  needed  on  seldomly  used  quarries.  This  is  similar  to  the  three 
month  certification  and  also  certifies  the  quality  of  materials. 

The  fourth  type  of  certification  Is  for  gravel  slag  and  sand  sources. 
These  tests  are  performed  every  year  as  a  certification  of  the  sites. 

INFORMATION  FLOW: 

For  all  certifications,  information  flow  is  similar  to  the  sample  manage- 
ment system. 

CENTRAL  OFFICE  INTERFACE: 

The  central  office  receives  all  information  from  each  of  the  four  types  of 
tests  and  uses  this  Information  to  document  the  quality  of  the  aggregate 
supply. 

EXISTING  FORMS:  lT-530,  IT-601 

REMARKS: 


DIVISION:  Materials  and  Testing 

SYSTEM:  Material  Sample  Management 

PURPOSE: 

The  purpose  of  the  Material  Sample  Management  system  is  to  keep  track 
of  all  construction  samples  and  test  reports.  Accurate  and  timely  record 
keeping  is  of  prime  importance,  as  construction  can  be  delayed  until  the 
material  is  certified.  Sample  test  data  are  incorporated  into  the  final  con- 
struction record,  and  serves  as  legal  documentation  in  the  case  of  a 
lawsuit.  Test  sample  information  can  be  incorporated  into  a  pavement 
management  system. 

DESCRIPTION: 

The  information  generated  from  the  test  reports  includes  the  tests  per- 
formed, and  whether  the  sample  passed  specifications.  After  the  testing 
and  calculations  are  completed,  the  information  is  compiled  into  a  report 
format  and  stored  at  the  district  office  and  the  central  lab. 

INFORMATION  FLOW: 

A  request  for  a  test  is  usually  initiated  by  the  contractor  by  notifying  the 
producer  and  the  proper  area  lab.  The  inspector  assigned  to  the  site  will 
fill  out  an  IT-530  form,  and  either  perform  the  test  or  send  it  and  the  sam- 
ple to  the  district  office  for  testing.  An  inspector  will  then  test  the  sample 
and  enter  the  results  on  an  IT-576-H  form.  This  form  then  goes  to  the 
project  engineer.  The  results  are  entered  on  the  IBM  3276  terminal  by 
the  Material  &  Testing  secretary  and  transferred  to  the  central  office.  As 
the  secretary  inputs  the  information  into  the  terminal,  she  makes  sure  the 
information  is  as  accurate  as  possible.  Information  flows  the  same  for 
concrete  and  asphalt  inspections  (Forms  IT-600  (asphalt)  and  IT-652 
(concrete)). 

CENTRAL  OFFICE  INTERFACE: 

Some  samples  cannot  be  tested  at  the  district  due  to  the  complexity  of 
the  test.  In  this  case,  the  sample  is  sent  to  the  central  office.  Also  infor- 
mation concerning  samples  tested  at  the  district  office  are  sent  via  the 
IBM  3276  terminal  to  the  central  office. 

EXISTING  FORMS:  IT-530,  IT-576-H  IT-600,  IT-652,  TD-497,  IT601, 
IT613E 

REMARKS: 


DIVISION:  Materials  &  Testing 
SYSTEM:  Independent  Assurance 

PURPOSE: 

The  independent  assurance  system  serves  as  a  independent  check  of 
the  inspectors,  test  procedures,  equipment,  and  materials.  It  is  to  ensure 
quality  and  accuracy  in  the  inspection  and  testing  methods  for  sources  of 
aggregates,  asphalts  and  concrete. 

DESCRIPTION: 

An  independent  assurance  inspector  samples  and  tests  materials  used 
on  all  projects  at  a  frequency  established  in  the  "Manual  for  Frequency  of 
Sampling  and  Testing  and  Basics  of  Use  of  Materials".  The  independent 
assurance  representative  will  run  the  same  test  as  the  inspector  and 
record  all  results  on  the  IT-576-H  ,  IT600  and  IT652.  Test  discrepancies 
are  compared  and  appropriate  action  is  taken. 

INFORMATION  FLOW: 

The  information  is  passed  between  the  inspector's  supervisor,  the  central 
offices,  and  the  project  engineers. 

CENTRAL  OFFICE  INTERFACE: 

Central  office  monitors  the  system  and  receives  copies  of  all  reports. 

EXISTING  FORMS:   IT-576-H,  IT-601 ,  TD-467.  TD-465,  IT-600.  IT652. 
TD-320G 

REMARKS: 


DIVISION:  Materials  and  Testing 
SYSTEM:  Site  Inspectof  Assignments 

PURPOSE: 

The  purpose  is  to  assign  inspectors  to  appropriate  inspection  sites. 

DESCRIPTION: 

The  materials  and  testing  area  is  responsible  for  assigning  site  inspec- 
tors to  the  different  labs,  processing  plants,  and  work  sites.  The  criteria 
is  usually  based  on  the  proximity  of  the  site  to  the  inspector's  home. 

INFORMATION  FLOW: 

All  information  is  maintained  by  the  district  testing  engineer. 

CENTRAL  OFFICE  INTERFACE: 
None. 


REMARKS: 

Each   District  approaches  this  task  differently   in   regards  personnel 
responsible  for  site  assignment. 


DIVISION:  Materials  &  Tests 
SYSTEM:  Test  Repofts 


PURPOSE: 

The  purpose  of  test  reports  is  to  have  uniform  criterion  and  uniform 
reporting  of  all  test  reports. 

DESCRIPTION: 

Test  reports  are  generated  whenever  any  material  is  tested.  The  type  of 
test  report  is  dependent  upon  the  material  being  tested  and  the  material 
usage.  Test  reports  are  used  as  a  legal  document  for  compliance  with 
material  codes  and  specifications.  Tests  are  performed  on  prescribed 
volumes  of  materials,  according  to  a  frequency  schedule. 

INFORMATION  FLOW: 

The  test  report  is  generated  while  the  test  is  performed.  The  test  results, 
as  well  as  the  raw  data  are  sent  to  the  Central  Office  where  they  are 
recorded  and  stored.  A  computer  generated  formal  report  is  sent  to  both 
the  project  engineer  and  the  district  office. 

CENTRAL  OFFICE  INTERFACE: 

The  central  office  acts  to  collect  test  data  and  to  generate  the  formal  test 
report. 

EXISTING  FORMS: 

REMARKS: 


DIVISION:  Materials  &  Tests 
SYSTEM:  Material  Analysis 


PURPOSE: 

The  purpose  of  material  analysis  is  to  certify  the  quality  of  all  construction 
materials. 

DESCRIPTION: 

Material  analysis  is  performed  in  conjunction  with  every  test  report.  Out- 
side of  data  collection  and  material  identification,  the  analysis  makes  up 
the  body  of  the  report  and  is  considered  to  be  the  most  important  and 
time  consuming.  Each  type  of  material  requires  uniform  tests  and  calcu- 
lations. These  calculations  can  be  readily  automated  as  they  are  repeti- 
tious in  nature  and  uniform  for  each  material. 

INFORMATION  FLOW: 

Test  reports  are  sent  to  the  central  office,  the  district  office,  and  the  pro- 
ject engineer. 

CENTRAL  OFFICE  INTERFACE: 

Central  office  receives  and  monitors  all  test  reports. 

EXISTING  FORMS: 

REMARKS: 


DIVISION:  Traffic 

SYSTEM:  Tfouble  Call  Log 


PURPOSE: 

The  purpose  of  the  trouble  call  log  is  to  keep  a  legal  document  that 
details  the  response  of  IDOH  to  problems  on  the  highway. 

DESCRIPTION: 

The  trouble  call  log  is  a  simple  notebook  filled  in  with  relevant  information 
about  each  call.  This  information  includes  the  location,  problem,  the  time 
of  the  call,  the  response  and  time  of  response. 

INFORMATION  FLOW: 

The  information  is  logged  at  the  time  of  the  call  whether  the  call  ori- 
ginates from  the  police  or  a  civilian.  The  problem  is  relayed  to  the 
responsible  contractor,  or  the  appropriate  district  employee.  The  trouble 
call  log  stays  at  the  district. 

CENTRAL  OFFICE  INTERFACE: 

The  central  office  may  require  this  information  in  the  case  of  a  lawsuit. 
Otherwise  it  is  not  of  interest  to  the  central  office. 

EXISTING  FORMS:  Trouble  Call  Sheet 

NEW  FORM  APPROVED:  State  Form  31868 

REMARKS: 


DIVISION:  Traffic 

SYSTEM:  CfGw  Day  Cards 


PURPOSE: 

The  purpose  of  the  crew  day  cards  is  to  monitor  and  budget  day  to  day 
maintenance  activities. 


DESCRIPTION: 

The  crew  day  card  is  sorted  by  pre-printed  activities,  such  as  sign  repair, 
painting,  etc.  At  the  end  of  a  work  day  the  crew  leader  fills  in  the 
appropriate  information.  This  information  includes  the  personnel 
involved,  the  work  accomplished,  the  location  of  the  work,  the  equipment 
used,  the  time  spent  on  the  activities,  and  any  comments. 

INFORMATION  FLOW: 

The  crew  day  card  is  initiated  at  the  subdistrict  and/or  unit  level.  These 
are  sent  to  the  district  office  where  the  information  is  compiled.  The 
cards  are  then  sent  to  the  central  office.  The  districts  use  the  information 
to  complete  daily  summary  sheets  and  monthly  productivity  reports.  At 
the  district  level  each  crew  day  card  is  keypunched  into  the  central  office 
computer. 

CENTRAL  OFFICE  INTERFACE: 

The  central  office  uses  this  information  to  schedule  future  work,  and  to 
compare  work  progress  with  that  scheduled. 

EXISTING  FORMS:  None. 

REMARKS: 


DIVISION:  Traffic 

SYSTEM:  Signal  Inventory 


PURPOSE: 

The  purpose  of  the  signal  inventory  is  to  keep  an  up  to  date  report  on  the 
location  and  condition  of  all  signs. 

DESCRIPTION: 

Signals  are  entered  into  the  log  by  type,  date  installed,  and  location.  The 
signal  inventory  also  includes  maintenance  and  contractual  information. 

INFORMATION  FLOW: 

When  a  new  signal  is  added,  or  when  a  signal  is  repaired  the  relevant 
information  is  added  to  the  log.  The  log  stays  within  the  District. 

CENTRAL  OFFICE  INTERFACE: 
None. 

EXISTING  FORMS:  None. 

REMARKS: 


DIVISION:  Traffic 
SYSTEM:  Paipit  Records 


PURPOSE: 

The  purpose  of  the  paint  record  is  to  provide  an  Inventory  ol  where  and 
when  a  road  was  last  painted,  and  the  composition  of  the  paint  used. 

DESCRIPTION: 

The  paint  record  is  kept  on  a  map  of  the  district.  The  map  is  marked 
according  to  the  status  of  the  road;  whether  the  road  has  or  hasn't  been 
painted  that  year,  and  when  It  was  last  painted. 

INFORMATION  FLOW: 

The  paint  record  stays  in  the  district. 

CENTRAL  OFFICE  INTERFACE: 

The  central  office  can  monitor  painting,  but  only  through  the  crew  day 
cards. 

EXISTING  FORMS:  Crew  Day  Cards 

REMARKS: 


r 


DIVISION:  Traffic 

SYSTEM:  Roadway  Investigations 

PURPOSE: 

The  purpose  of  the  roadway  investigation  is  to  monitor  changes  in  traffic 
patterns  and  to  adjust  signal  timing,  road  conditions,  speed  limits,  etc... 

DESCRIPTION: 

In  each  district  there  are  several  investigation  teams  with  the  sole  task  of 
analyzing  and  upgrading  traffic  flow.  They  must  be  aware  of  roadway 
changes,  business  development,  and  community  expansion. 

INFORMATION  FLOW: 

The  team  will  investigate  flow  changes  from  any  development  as  well  as 
responding  to  public  traffic  complaints.  If  change  is  warranted,  a  report  is 
filed  and  mailed  to  the  central  office. 

CENTRAL  OFFICE  INTERFACE: 

The  central  office  reviews  major  roadway  changes. 

EXISTING  FORMS:  None. 

REMARKS: 


DIVISION:  Traffic 

SYSTEM:  Road  Closufe  Log 


PURPOSE: 

The  purpose  of  the  road  closure  log  Is  to  maintain  a  history  as  to  what 
steps  were  taken  to  inform  the  public  of  road  closures. 

DESCRIPTION: 

The  information  includes  which  roads  were  closed,  between  which  inter- 
sections, and  the  length  of  time  the  road  was  closed,  and  what  steps 
were  taken  to  notify  public  agencies. 

INFORMATION  FLOW: 

The  project  engineer  sends  the  information  to  the  development  engineer 
who  contacts  the  media  via  press  release.  They  aim  for  two  week  notice 
of  all  road  closures. 

CENTRAL  OFFICE  INTERFACE: 
None. 

EXISTING  FORMS:  None. 

REMARKS: 


DIVISION:  Traffic 

SYSTEM:  llluiTiination  Outage  Summary 

PURPOSE: 

The  purpose  of  the  Highway  Illumination  Outage  Summary  is  to  record  highway 
illumination  outages  discovered  by  surveillance  inspectors. 

DESCRIPTION: 

Outages  are  entered  by  pole  identification  number  and  are  cross  referenced  to  a 
highway  illumination  inventory  as  a  validity  check.  The  recorded  outages  will 
generate  various  report  summaries. 

INFORMATION  FLOW: 

Outages  are  logged  following  scheduled  surveillance  by  district  traffic.  Reports 
are  forwarded  to  the  following: 

1 .  Maintenance  Agency  (frequency  may  vary) 

2.  Electrical  Utility  (monthly) 

3.  Central  Office  (monthly) 

4.  TM  contract  project  engineer  (monthly) 

CENTRAL  OFFICE  INTERFACE: 

Monthly  summaries  are  sent  to  the  central  office  for  tabulation  and  review  of 
outages  on  state  wide  basis. 

EXISTING  FORMS:  Highway  &  Sign  Lighting  Outage  Report 

REMARKS: 

Presently  this  task  is  done  manually  and  is  very  time  consuming.  The  value  in 
continuing  this  process  has  resulted  in  obtaining  credits  from  electrical  utilities 
and  maintenance  contractors.  The  use  of  a  computer  would  widen  the  margin 
between  benefits  vs.  costs.  This  system  could  be  further  sub-divided  or  related 
to  other  inventories  such  as: 

1 .  Tm  Contract  Progressive  Estimate 

2.  Utility  Agreement  Inventory 

3.  Highway  Illumination  Inventory 


DIVISION:  Traffic 

SYSTEM:  TM  Pfogressive  Estimate 

PURPOSE: 

The  purpose  of  the  TM  Contract  Progressive  Estimate  is  to  log  contract 
items  used  by  the  contractor. 

DESCRIPTION: 

TM  contracts  consist  of  maintenance  for  traffic  signals  or  highway  illumi- 
nation. Reports  for  each  location  worked  are  received  monthly  from  the 
contractor.  Each  report  is  logged  by  location,  date,  and  contract 
Items/quantities.  A  monthly  summary  is  produced  to  substantiate  billing 
and  prepare  monthly  estimate  for  payment.  Records  are  maintained 
through  project  completion  to  generate  final  construction  record. 

INFORMATION  FLOW: 

The  project  engineer  maintains  all  records. 

CENTRAL  OFFICE  INTERFACE: 
None 

EXISTING  FORMS:  None 

REMARKS: 

This  can  be  Interfaced  with  traffic  signal  and  highway  illumination  inven- 
tory to  generate  maintenance  records/costs  on  a  unit  or  inventory  type 
basis  for  evaluation  of  maintenance  techniques,  product  dependability, 
flag  re-occurrence  of  problems,  etc. 

At  the  present  time,  one  TM  contract  for  traffic  signals  generates 
over  2000  reports  submitted  by  a  contractor.  A  computer  system  would 
provide  access  to  information  presently  not  available. 


DIVISION:    All 

INFORMATION  SYSTEM:    PayfOll  VOUChef 

PURPOSE: 

The  purpose  of  the  payroll  voucher  is  to  keep  a  record  of  the  employees' 
work  hours. 

DESCRIPTION: 

Pay  vouchers  are  weekly  or  bi-weekly  "time  cards",  and  are  used  to 
account  for  all  IDOH  work  hours. 

INFORMATION  FLOW: 

Prior  to  payday,  all  IDOH  employees  fill  out  a  pay  voucher  with  hours 
worked,  account  numbers,  vacation  days,  supervisor's  signature,  etc... 
These  are  collected  at  the  district  and  sent  to  the  central  office  by  courier. 
Paychecks  are  issued  out  of  the  central  office. 

CENTRAL  OFFICE  INTERFACE: 

The  pay  vouchers  are  sent  to  the  central  office  for  processing  employee 
paychecks.  The  paychecks  are  then  sent  from  the  central  office  via  per- 
sonal carrier  to  the  district  and  distributed  from  there. 

EXISTING  FORMS:  State  Form  3756R2 
Indiana  Department  of  Highways 
Payroll  Voucher 

REMARKS: 


DIVISION:  All 

SYSTEM:  VehJcle  Control 


PURPOSE: 

The  purpose  of  a  vehicle  control  system  is  to  keep  track  of  vehicle  usage 
for  preventive  nnaintenance  and  for  the  vehicle  inventory. 

DESCRIPTION: 

The  vehicle  control  system  consists  of  the  vehicle  usage  logs,  parts  tran- 
saction documents  for  fuel,  and  maintenance  logs.  The  usage  logs  are 
filled  out  by  the  individuals  who  are  assigned  state  vehicles.  These  keep 
track  of  mileage  and  fuel  and  are  collected  monthly. 

INFORMATION  FLOW: 

Personnel  assigned  state  vehicles  turn  in  usage  logs  every  month  to  their 
division  secretary.  The  secretary  checks  over  this  information  and  sends 
it  to  the  district  administration  office  to  be  sent  to  the  central  office.  Any 
information  regarding  maintenance  done  on  the  vehicle  is  also  sent  to  the 
district  administration  office  and  to  the  central  office.  This  information  is 
used  by  the  preventive  maintenance  system  for  scheduling  vehicle 
maintenance. 


CENTRAL  OFFICE  INTERFACE: 

All  information  is  sent  to  the  central  office  as  part  of  the  preventive 
maintenance  system. 

EXISTING  FORMS:  None 

REMARKS: 


DIVISION:    All 

SYSTEM:  RequJsition  Forms 


PURPOSE: 

The  purpose  of  the  requisition  is  to  allow  for  procurement  of  needed 
equipment/materials. 

DESCRIPTION: 

There  are  three  procurement  systems,  the  requisition  system,  the 
confirming  requisition  system,  and  the  petty  cash  system.  Each  system 
is  defined  to  handle  procurement  of  increasing  expense. 

The  petty  cash  system  allows  for  procurement  of  goods  with  a  price 
under  fifty  dollars.  This  system  is  informal  and  administered  through  the 
district  administrative  manager. 

The  confirming  requisition  system  is  for  the  procurement  of  goods 
with  a  price  tag  of  fifty  dollars  to  $500.  Goods  are  purchased  when 
needed,  but  payment  is  issued  out  of  central  office. 

The  requisition  system  is  for  procurement  of  items  costing  more 
than  $500.  The  items  are  purchased  through  central  office  and  through 
an  open  bid  process. 

INFORMATION  FLOW: 

Every  district  and  subdistrict  has  a  material/equipment  budget.  For  petty 
cash  items  (eg.  a  hammer,  nails,  etc..)  the  district  administrator  is 
notified  and  the  item  is  purchased.  The  DAM  reimburses  the  purchaser  in 
cash,  and  a  petty  cash  report  is  sent  to  the  central  office  with  the  receipt. 
The  central  office  will  "refill"  the  petty  cash  fund. 

For  confirming  requisition  items,  the  materials  are  purchased  and 
payment  charged  to  the  central  office.  All  confirming  requisition  pur- 
chases must  be  within  the  division's  budget.  Confirming  requisition  forms 
are  sent  to  the  central  office  and  payment  is  issued  to  the  vendor  directly 
from  central  office. 

Requests  for  materials  through  the  requisition  system  is  made  to 
central  office.  Again  this  must  be  within  the  quarterly  budget.  At  Indi- 
anapolis, if  they  approve  the  requisition,  then  the  requisition  goes  out  for 
bids,  or  if  the  material  is  stored,  it  will  be  sent  to  the  district. 

CENTRAL  OFFICE  INTERFACE: 

All  requisitions  have  to  go  to  the  central  office  for  bidding  or  for  issuance. 


All    Requisition  Forms 


EXISTING  FORMS:  State  Form  2638R3 
REMARKS: 


DIVISION:  All 

SYSTEM:  Inventopy 


PURPOSE: 

The  purpose  of  the  inventory  is  to  keep  track  of  all  assets  of  the  IDOH. 
This  includes  furniture,  vehicles,  equipnnent,  etc... 

DESCRIPTION: 

IDOH  inventories  all  assets  twice  a  year.  The  expected  inventory  is 
logged  in  a  computer  generated  printout  consisting  of  all  items  listed  in 
the  last  inventory.  Each  division  compares  this  printout  with  their  actual 
physical  inventory. 

INFORMATION  FLOW: 

The  printout  is  sent  to  the  district  administration  office  and  distributed 
among  each  division.  In  each  division  the  inventory  is  updated  and  then 
sent  to  the  centraloffice  via  the  district  administrator. 

CENTRAL  OFFICE  INTERFACE: 

The  central  office  will  receive  the  updated  inventories  from  the  district 
administration  office. 


EXISTING  FORMS:  None 

REMARKS: 

The  inventory  process  is  long  and  tedious  for  districts  personnel.  This 
could  be  alleviated  by  keeping  a  running  inventory  in  the  district  offices. 


